|
 |
|
| |
7.2.15. How to Avoid Table Scans
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
ON or WHERE clause 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, “WHERE Clause 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.
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 TABLE
tbl_name to update the
key distributions for the scanned table. See
Section 13.5.2.1, “ANALYZE TABLE Syntax”.
-
Use FORCE INDEX for 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;
See Section 13.2.7, “SELECT Syntax”.
Start mysqld with the
--max-seeks-for-key=1000 option or use
SET max_seeks_for_key=1000 to tell the
optimizer to assume that no key scan causes more than 1,000
key seeks. See Section 5.2.2, “Server System Variables”.
|
|
|
