Frequently, a full table
scan is a danger sign that a query can be speeded up
significantly. For tables with more than a few rows, consider
redesigning the query by adding an index for one or more of
the columns tested in the
WHERE clause. Put
extra effort into avoiding table scans for queries that
perform joins or reference foreign keys. If the nature of the
data means there is no way to avoid reading all the rows, then
it might not be practical to make the query faster, or making
it faster might involve extensive restructuring of your tables
that is beyond the scope of this section.
WHEREclauses do not reference any indexed columns that the query can use. Consider adding an index, or refining those clauses to refer to an indexed column.
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.
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 126.96.36.199, “WHERE Clause Optimization”. For example, to query census data only for males or only for females, MySQL must read most of the data blocks in the table, so locating the rows through the index would add unnecessary overhead. If these reports are frequent or truly time-critical, and the table is huge, you might partition, shard, or create dimension tables using the relevant column.
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:
ORkeywords in your
WHEREclauses. If there is no index that helps to locate the values on both sides of the
OR, any row could potentially be part of the result set, so all rows must be tested, and that requires a full table scan. If you have one index that helps to optimize one side of an
ORquery, and a different index that helps to optimize the other side, use a
UNIONoperator to run separate fast queries and merge the results afterward.
With tables that use the
MEMORYstorage engine, if you run queries that examine ranges of values (using operators such as
BETWEENon the indexed columns), create the index with the
USING BTREEclause. The default (
USING HASH) is fast for retrieving individual rows with an equality operator (
<=>), but is much slower (requiring a full table scan) to examine a range of column values. A
MEMORYtable created with the
USING BTREEclause is still fast for equality comparisons, so use that clause for your
MEMORYtables that handle a variety of queries.
ANALYZE TABLEto update the key distributions for the scanned table. See Section 188.8.131.52, “ANALYZE TABLE Syntax”.
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 use
SET 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.7, “Server System Variables”.