Systems for MySQLThe world's most popular open source database
- 7.2 Optimizing SELECT and Other Statements
- 7.2.1 Optimizing Queries with EXPLAIN
- 7.2.2 Estimating Query Performance
- 7.2.3 Speed of SELECT Queries
- 7.2.4 WHERE Clause Optimization
- 7.2.5 Range Optimization
- 7.2.6 Index Merge Optimization
- 7.2.7 Condition Pushdown Optimization
- 7.2.8 IS NULL Optimization
- 7.2.9 LEFT JOIN and RIGHT JOIN Optimization
- 7.2.10 Nested Join Optimization
- 7.2.11 Outer Join Simplification
- 7.2.12 ORDER BY Optimization
- 7.2.13 GROUP BY Optimization
- 7.2.14 DISTINCT Optimization
- 7.2.15 Optimizing IN/=ANY Subqueries
- 7.2.16 LIMIT Optimization
- 7.2.17 How to Avoid Table Scans
- 7.2.18 INFORMATION_SCHEMA Optimization
- 7.2.19 Speed of INSERT Statements
- 7.2.20 Speed of UPDATE Statements
- 7.2.21 Speed of DELETE Statements
- 7.2.22 Other Optimization Tips
The output from EXPLAIN shows
ALL in the type column
when MySQL uses a table scan to resolve a query. This usually
happens under the following conditions:
The table is so small that it is faster to perform a table scan than to bother with a key lookup. This is common for tables with fewer than 10 rows and a short row length.
There are no usable restrictions in the
ONorWHEREclause for indexed columns.You are comparing indexed columns with constant values and MySQL has calculated (based on the index tree) that the constants cover too large a part of the table and that a table scan would be faster. See Section 7.2.4, “
WHEREClause Optimization”.You are using a key with low cardinality (many rows match the key value) through another column. In this case, MySQL assumes that by using the key it probably will do many key lookups and that a table scan would be faster.
MySQL Enterprise. For expert advice on avoiding excessive table scans subscribe to the MySQL Enterprise Monitor. For more information, see http://www.mysql.com/products/enterprise/advisors.html.
For small tables, a table scan often is appropriate and the performance impact is negligible. For large tables, try the following techniques to avoid having the optimizer incorrectly choose a table scan:
Use
ANALYZE TABLEto update the key distributions for the scanned table. See Section 12.5.2.1, “tbl_nameANALYZE TABLESyntax”.-
Use
FORCE INDEXfor the scanned table to tell MySQL that table scans are very expensive compared to using the given index:SELECT * FROM t1, t2 FORCE INDEX (
index_for_column) WHERE t1.col_name=t2.col_name; Start mysqld with the
--max-seeks-for-key=1000option or useSET max_seeks_for_key=1000to tell the optimizer to assume that no key scan causes more than 1,000 key seeks. See Section 5.1.3, “System Variables”.
User Comments
What I missed here was a hint on how to tell MySQL in which order to join tables to improve performance. I spent some time looking for a way to accomplish this, finally I found it somewhere else in the manual. STRAIGHT_JOIN does the trick!
Add your own comment.