Esto se debe a lo que yo llamo la regla del 5 % basada en la población clave (cardinalidad de tuplas).
Si indexa una tabla en la que existe una cardinalidad asimétrica, MySQL Query Optimizer siempre elegirá la ruta de menor resistencia.
EJEMPLO:si una tabla tiene una columna de género, la cardinalidad es dos, M y F.
¿Qué es lo que indexa esa columna de género? Esencialmente obtienes dos listas enlazadas gigantes.
Si carga un millón de filas en una tabla con una columna de género, puede obtener 50 % M y 50 % F.
Un índice se vuelve inútil durante la optimización de consultas si la cardinalidad de un combo clave (población clave como lo expresé) es más del 5% del recuento total de la tabla.
Ahora, con respecto a su ejemplo, ¿por qué los dos planes EXPLAIN diferentes? Mi conjetura es MySQL Query Optimizer e InnoDB como un equipo de etiqueta.
En el primer CREATE TABLE, la tabla y los índices tienen aproximadamente el mismo tamaño aunque son pequeños, por lo que se decidió a favor del índice haciendo un escaneo de índice, no un escaneo de tabla completo . Tenga en cuenta que los índices no únicos llevan la clave principal interna de cada fila (RowID) en sus entradas de índice, lo que hace que los índices tengan casi el mismo tamaño que la tabla misma.
En la segunda CREAR TABLA, debido a la introducción de otra columna, usuario, ahora hace que el Optimizador de consultas vea un escenario completamente diferente:la tabla ahora es más grande que los índices . Por lo tanto, el Optimizador de consultas se volvió más estricto en su interpretación de cómo usar los índices disponibles. Fue a la regla del 5% que mencioné antes. Esa regla falló estrepitosamente y el Optimizador de consultas decidió realizar un análisis completo de la tabla.
