Soy consciente de que en los índices de MySQL en (A,B,C) se benefician las cláusulas ANDed WHERE con |A|, |A,B|, |A,B,C|. Esto hace que parezca que tener el índice (A,B,C) significa que no tiene sentido tener un solo índice en (A) o un compuesto en (A,B).
1. ¿Es esto cierto?
2. ¿Es simplemente un desperdicio mantener un índice en (A) cuando ya tiene un índice en (A, B, C)?
Creo que la respuesta a sus dos preguntas es la misma: es casi completamente cierto; casi siempre es un desperdicio tener índices tanto en (A, B, C) como en (A).
Como mencionó Danblack, el tamaño podría hacer una pequeña diferencia, aunque probablemente sea insignificante.
Más importante aún, en mi experiencia, tenga en cuenta que (A) es en realidad (A, Primaria), donde Primaria son aquellas columnas de clave principal que aún no están explícitamente incluidas en el índice. En la práctica, eso a menudo significa (A, Id). El otro índice, entonces, es en realidad (A, B, C, Id). Tenga en cuenta cómo afecta esto al orden en que se encuentran las filas en el índice.
Imagina hacer esto:
SELECT * FROM MyTable WHERE A = 'Whatever' ORDER BY IdIndex (A), AKA (A, Id), es perfecto para esto. Para cualquier valor fijo de A, las filas correspondientes se ordenan por Id. No es necesario clasificarlos: los resultados están en el orden deseado.
Sin embargo, para el índice (A, B, C), AKA (A, B, C, Id), es diferente. ¡Para cualquier valor fijo de A, las filas correspondientes se ordenan por B! Esto significa que la consulta anterior requerirá la clasificación de los resultados.
EXPLAIN debería confirmar lo que he descrito. Se realizará una filesort de archivos si solo está disponible el índice (A, B, C), pero no si (A) está disponible.
Debería ser fácil ver que esto importa muy poco si generalmente hay muy pocas filas para un valor particular de A. Sin embargo, si pudiera haber 100,000 filas para tal valor, entonces la filesort de archivos comienza a tener un impacto. En tal caso, puede elegir tener un índice (A) para optimizar para este escenario.
En términos generales, tales índices de prefijos son superfluos. Sin embargo, es bueno analizar sus índices y consultas para identificar estos escenarios. En un caso raro, puede valer la pena agregar uno. En el caso más común, al menos podrá sopesar tales efectos en sus opciones generales de índice.
verdadero
casi siempre
Hay un caso muy raro que si:
A como índice independiente se usa con mayor frecuencia, yA,B o A,B,C son muy raras, ysizeof(A) es significativamente menor que el sizeof(A,B,C) , yA,B,C utiliza un tamaño de grupo de búfer/tamaño de caché de clave significativo para impedir otras consultas; entonces puede haber un gran beneficio al tener un pequeño subconjunto duplicado de un índice A .
Nota: posiblemente podría incluir otras condiciones