:: DEVELOPER ZONE
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's faster to do a table scan than a key lookup. This is a common case 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, “How MySQL Optimizes WHERE Clauses”.
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 does a lot of key lookups and that a table scan would be faster.
For small tables, a table scan often is appropriate. For large tables, try the following techniques to avoid having the optimizer incorrectly choose a table scan:
Use ANALYZE TABLE to update the key distributions for the
scanned table. See Section 13.5.2.1, “tbl_nameANALYZE TABLE Syntax”.
Use FORCE INDEX for the scanned table to tell MySQL that table
scans are very expensive compared to using the given index.
See Section 13.1.7, “SELECT Syntax”.
SELECT * FROM t1, t2 FORCE INDEX (index_for_column) WHERE t1.col_name=t2.col_name;
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.3, “Server System Variables”.
© 1995-2005 MySQL AB. All rights reserved.

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.