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 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
Sección 7.2.4, “Optimización de las cláusulas WHERE
por parte de
MySQL”.
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
Sección 13.5.2.1, “Sintaxis de tbl_name
ANALYZE TABLE
”.
Use FORCE INDEX
for the scanned table to
tell MySQL that table scans are very expensive compared to
using the given index. See Sección 13.2.7, “Sintaxis de SELECT
”.
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 Sección 5.3.3, “Variables de sistema del servidor”.
Ésta es una traducción del manual de referencia de MySQL, que puede encontrarse en dev.mysql.com. El manual de referencia original de MySQL está escrito en inglés, y esta traducción no necesariamente está tan actualizada como la versión original. Para cualquier sugerencia sobre la traducción y para señalar errores de cualquier tipo, no dude en dirigirse a mysql-es@vespito.com.