1 Famously, people often used MySQL as a queue and then learned the hard way why it was bad. The most cited
reasons were the overhead of polling for new queue actions, the management of locking records for process‐
ing, and the unwieldy size of queue tables as data grows over time.
What Is Dierent in This Edition
High Performance MySQL has been a part of the database engineering community for
years, with past editions released in 2004, 2008, and 2012. In these previous editions,
the goal was always to teach developers and administrators how to optimize MySQL
for every drop of performance by focusing on deep internal design, explaining what
various tuning settings mean, and arming the user with the knowledge to be effective
in changing these settings. This edition maintains the same goal but with a different
focus.
Since the third edition, the MySQL ecosystem has seen a lot of changes. Three new
major versions have been released. The tooling landscape expanded significantly
beyond Perl and Bash scripts and into full-fledged tooling solutions. Entirely new
open source projects have been built that change how organizations manage scaling
MySQL.
Even the traditional database administrator (DBA) role has evolved. There’s an old
joke in the industry that says that DBA stands for “Don’t Bother Asking.” DBAs had a
reputation for being speed bumps in the software development life cycle (SDLC), not
explicitly because of any curmudgeonly attitude, but simply because databases weren’t
evolving as fast as the rest of the SDLC around them.
With books like Database Reliability Engineering: Designing and Operating Resilient
Database Systems by Laine Campbell and Charity Majors (O’Reilly), it has become the
new reality that technical organizations look to database engineers more as enablers
of business growth and less as the sole operators of all databases. Where once a DBA’s
primary day-to-day involved schema design and query optimization, they now are
responsible for teaching those skills to developers and managing systems that allow
developers to deploy their own schema changes quickly and safely.
With these changes, the focus should no longer be on optimizing MySQL to get a few
percentage points faster. We think that High Performance MySQL is now about giving
people the information they need to make educated decisions about how to best use
MySQL. This begins by understanding how MySQL is designed, which gives way to
understanding what MySQL is and is not good at.
1
Modern releases of MySQL offer
reasonably sane defaults, and there’s very little tuning you need to do unless you’re
experiencing a very specific scaling problem. Modern teams are now dealing with
schema changes, compliance issues, and sharding. We want High Performance MySQL
to be a comprehensive guide to how modern companies run MySQL at scale.
xvi | Preface
