High.Performance.MySQL 读书笔记
chapter 6 Query Performance Optimization
Optimize Data Access
Slow Query Basics: Optimize Data Access
We’ve found it useful to analyze a poorly performing query in two steps:
- Find out whether your application is retrieving more data than you need. That usually means it’s accessing too many rows, but it might also be accessing too many columns.
- Find out whether the MySQL server is analyzing more rows than it needs.
Are You Asking the Database for Data You Don’t Need?
Fetching more rows than needed
Fetching all columns from a multitable join
Fetching all columns（SELECT *.）
Fetching the same data repeatedly
Is MySQL Examining Too Much Data?
the simplest query cost metrics are:
• Response time
（1）service time and queue time
（2）quick upper-bound estimate (QUBE) of query response time using the techniques explained in Tapio Lahdenmaki and Mike Leach’s book Relational Database Index Design and the Optimizers (Wiley)
• Rows examined and rows returned
• Rows examined and access types
（1）The access types range from a full table scan to index scans, range scans, unique index lookups, and constants. Each of these is faster than the one before it, because it requires reading less data.
（2） Indexes let MySQL find rows with a more efficient access type that examines less data.
（3）In general, MySQL can apply a WHERE clause in three ways, from best to worst:
• Apply the conditions to the index lookup operation to eliminate nonmatching rows. This happens at the storage engine layer.
• Use a covering index (“Using index” in the Extra column) to avoid row accesses, and filter out nonmatching rows after retrieving each result from the index. This happens at the server layer, but it doesn’t require reading rows from the table.
• Retrieve rows from the table, then filter nonmatching rows (“Using where” in the Extra column). This happens at the server layer and requires the server to read rows from the table before it can filter them.