Don’t have time to read Efficient MySQL Performance? Here’s the book (10 chapters) in one-liners.

1. Performance is query response time.
2. Proper left-most indexing is required for performance.
3. The less data, the better.
4. Access patterns (part of the workload) help or hinder performance.
5. Sharding is how to scale writes when single-node performance is truly reached.
6. Server metrics reflect how the app workload causes MySQL to work.
7. Replication lag is data loss.
8. Locks are held until a transaction commits, so commit quickly.
9. There are many other challenges that you might need to address—sorry.
10. MySQL in the cloud is slower and more expensive, so performance is more important than ever.

No, I don’t think so. But it is does change our profession and have important implications for software engineers using (not managing) MySQL.

No, I don’t think so. But it is does change our profession and have important implications for software engineers using (not managing) MySQL.

No, I don’t think so. But it is does change our profession and have important implications for software engineers using (not managing) MySQL.

Chapter 9 of Efficient MySQL Performance changed in development. Originally, it was a chapter titled “Not MySQL”, as in “how not to use MySQL.” But we (O’Reilly and I) pulled the chapter, and the current chapter 9 in print is “Other Challenges”: an important laundry list of other challenges engineers using MySQL must be aware of and address. This blog post is a sketch of the unwritten chapter 9: how not to use MySQL.

Chapter 9 of Efficient MySQL Performance changed in development. Originally, it was a chapter titled “Not MySQL”, as in “how not to use MySQL.” But we (O’Reilly and I) pulled the chapter, and the current chapter 9 in print is “Other Challenges”: an important laundry list of other challenges engineers using MySQL must be aware of and address. This blog post is a sketch of the unwritten chapter 9: how not to use MySQL.

Chapter 9 of Efficient MySQL Performance changed in development. Originally, it was a chapter titled “Not MySQL”, as in “how not to use MySQL.” But we (O’Reilly and I) pulled the chapter, and the current chapter 9 in print is “Other Challenges”: an important laundry list of other challenges engineers using MySQL must be aware of and address. This blog post is a sketch of the unwritten chapter 9: how not to use MySQL.

The MySQL Performance Schema is a gold mine of valuable data. Among the many nuggets you can extract from it is an historical report of transactions: how long a transaction took to execute, what queries were executed in it (with query metrics), and idle time between queries. Mining this information is not trivial, but it’s fun and this blog post shows how to start.

The MySQL Performance Schema is a gold mine of valuable data. Among the many nuggets you can extract from it is an historical report of transactions: how long a transaction took to execute, what queries were executed in it (with query metrics), and idle time between queries. Mining this information is not trivial, but it’s fun and this blog post shows how to start.

The MySQL Performance Schema is a gold mine of valuable data. Among the many nuggets you can extract from it is an historical report of transactions: how long a transaction took to execute, what queries were executed in it (with query metrics), and idle time between queries. Mining this information is not trivial, but it’s fun and this blog post shows how to start.