EXPLICAR el resultado sugiere que mi índice no se está utilizando

He configurado mi tabla con un índice solo en done_status (done_status = INT):

ingrese la descripción de la imagen aquí

Cuando uso:

EXPLAIN SELECT * FROM reminder  WHERE done_status=2

Me devuelve esto:

id select_type tipo de tabla possible_keys key key_len ref filas Extra
1 Recordatorio SIMPLE TODO done_status NULL NULL NULL 5 Uso de where

Pero cuando publico este comando:

EXPLAIN SELECT * FROM reminder  WHERE done_status=1

Me devuelve lo siguiente:

id select_type tipo de tabla possible_keys key key_len ref filas Extra
1 Recordatorio SIMPLE ref done_status done_status 4 const 2

El EXPLAINme muestra que usa 5 filas, la segunda vez 2 filas.

No creo que se use el índice, si lo entendí bien la primera vez debería darme 3 filas. ¿Qué hago mal?

SHOW INDEX FROM reminder:

Tabla Non_unique Key_name Seq_in_index Column_name Colation Cardinality Sub_part Packed Null Index_type Comment Index_comment
recordatorio 1 done_status 1 done_status A 5 NULL NULL BTREE

explicar extendido:

id select_type tipo de tabla possible_keys key key_len ref filas filtradas Extra
1 Recordatorio SIMPLE ref done_status done_status 4 const 2 100.00

show warnings no mostró nada de interés.

mysql

— Prueba el gran
fuente

Confía en mí, el índice funciona. Pero no puedo ver nada fácilmente en su captura de pantalla. ¿Puede hacer un "índice de presentación de yourtable"

Sí

use glorify \ G para el esquema y explique el resultado del plan, debería ser más legible

— ajreal

Por interés, ¿puede repetir con un "explicar extendido" y un "mostrar advertencias", esto mostrará la elección real de SQL mysql

@ajreal, ¿qué es glorificar?

Respuestas:

No entiendes qué es el campo 'filas'. Es el número de filas que mysql estima que necesitará leer para satisfacer su consulta. Este valor puede ser bastante inexacto. No significa que este sea el número de filas en el resultado, o el número real de filas leídas por mysql

¿Entonces? ¿Dónde dije que lo hace? ¿Qué elige el optimizador? El índice aún funciona.

@ajreal Sin embargo, no significa que el índice esté roto. Solo el optimizador elige (en su mente) la forma más eficiente de consultar los datos. Supuse que el OP esperaba que la columna de filas en EXPLICAR fuera exacta. No significa que el índice esté roto, solo que mysql elige no usarlo (probablemente).

@ajreal: me falta algo en tus puntos. La columna de filas de una explicación no tiene nada que ver con los índices, ¿verdad? Mysql elige no usar el índice (tal vez todos los datos están en una sola página). ¿No estoy seguro de que entiendo tu punto? La optimización de consultas en una tabla de 5 filas producirá algunos resultados "extraños" porque prácticamente no importa cómo se optimice.

vamos a continuar esta discusión en el chat

En este caso, ¿a quién le importa qué índice elige el optimizador? No hay nada de malo en el índice en sí, porque el optimizador sintió que no lo necesitaba, ¿qué importa?

La primera ejecución simple no es utilizar el índice con seguridad,
podría ser la información_esquema.las estadísticas del índice no se ponen al día con los datos después de algunas operaciones de escritura, o no se accede a la tabla durante mucho tiempo.

como se explica aquí: - ¿ De dónde lee MySQL Query Optimizer las estadísticas del índice?

para el segundo plan de ejecución, parece que information_schema.statistics ya se pone al día y soluciona el problema de cardinalidad NULL.

Por lo tanto, se ejecuta la consulta de acuerdo con el optimizador de índice.

Para la tabla con filas pequeñas, no importa mucho.
Pero los datos crecerán, el desarrollador siempre debe verificar esto
y realizar la tabla de análisis necesaria cuando la cardinalidad del encuentro sea nula en el índice.

— ajreal
fuente

El primer plan de ejecución no está utilizando un índice.

Desde el sitio web de referencia de MySQL :

A veces MySQL no usa un índice, incluso si hay uno disponible. Una circunstancia en la que esto ocurre es cuando el optimizador estima que usar el índice requeriría que MySQL acceda a un porcentaje muy grande de las filas de la tabla. (En este caso, es probable que una exploración de tabla sea mucho más rápida porque requiere menos búsquedas). Sin embargo, si dicha consulta usa LIMIT para recuperar solo algunas de las filas, MySQL usa un índice de todos modos, porque puede encontrar mucho más rápidamente las pocas filas para devolver en el resultado.

Si su tabla tiene solo 5 filas y su consulta selecciona 3 de ellas, entonces el optimizador de MySQL supone que es más eficiente escanear toda la tabla.

— Matthew Sammut
fuente