¿Es necesario tener un índice en cada combinación de campos consultables en una tabla SQL para optimizar el rendimiento?

Question

Si mi tabla User tiene varios campos que son consultables (digamos DepartmentId, GroupId, RoleId), ¿habrá alguna diferencia de velocidad si creo un índice para cada combinación de esos campos?

Por "consultable", me refiero a una pantalla de consulta donde el usuario final puede seleccionar registros en función del departamento, grupo o rol seleccionando desde un menú desplegable.

Por el momento, tengo un índice en DepartmentId, GroupId y RoleId. Es un índice único no único por campo.

Si un usuario final selecciona "nadie en el Grupo B", el SQL se parece a:

select * from User where GroupId = 2 

Tener un índice en GroupId debe acelerar ese proceso.

Pero si el usuario final seleccionar "nadie en el grupo B y en papel C", el SQL se vería así:

select * from User where GroupId = 2 and RoleId = 3 

Tener índices en GroupId y RoleId individual no puede hacer ninguna diferencia, ¿verdad?

Un mejor índice para esa búsqueda sería si tuviera un índice que abarcara ambos GroupId y RoleId.

Pero si ese es el caso, entonces eso significaría que necesitaría tener un índice para cada combinación de campos consultables. Por lo que iba a necesitar todos estos índices:

• DepartmentID
• GroupId
• RoleId
• DepartmentID y GroupId
• DepartmentID y RoleId
• GroupId y RoleId
• ID de departamento, GroupId y RoleId

¿Alguien puede arrojar algo de luz sobre esto? Estoy usando MySQL si eso hace la diferencia.

Answer 1

Se puede usar un índice de varias columnas para cualquier prefijo izquierdo de ese índice. Por lo tanto, un índice en (A, B, C) se puede usar para consultas en (A), (A, B) y (A, B, C), pero no puede, por ejemplo, usarse para consultas en (B) o (B, C).

Si todas las columnas están indizadas individualmente, MySQL (5.0 o posterior) también puede usar Index Merge Optimization.

Answer 2

Lo que he encontrado es que es mejor indexar cualquier cosa que el usuario busque. De hecho, he encontrado un mejor rendimiento al crear índices con varias columnas si se ejecuta una búsqueda de esas columnas.

Por ejemplo, si alguien puede buscar tanto en roleid como en groupid al mismo tiempo, tener un índice con ambas columnas en realidad será un poco más rápido que tener solo un índice en cada una. Sin embargo, tener un índice en cada columna consultable puede ser bueno, ya que puede perder una combinación de columnas.

Una consideración clave es ver cuánto espacio ocuparán los índices. Como estas columnas son campos enteros, no debería ser un gran problema. Un poco de tiempo creando índices podría cosechar beneficios significativos.

Lo mejor que se puede hacer es experimentar. Haz una búsqueda en varias columnas y mide el tiempo, luego agrega un índice combinado y vuelve a ejecutarlo.

Answer 3

Mi experiencia es con SQL Server en lugar de mysql y es posible que esto haga la diferencia. Sin embargo, en general, el motor puede usar múltiples índices en una sola consulta. Aunque sin duda hay beneficios de tener un índice único más completo (proporciona un impulso mayor, especialmente si forma un índice de cobertura), aún tendrá un beneficio al usar un índice en cada campo de la consulta.

Además, tenga en cuenta que cada índice se debe mantener por separado, por lo que sufrirá una reducción en el rendimiento de las operaciones de escritura a medida que su número de índices crezca.

Answer 4

Elimine todos los índices y ejecute sentencias CRUD contra la tabla con una herramienta gratuita llamada "SQL sentry plan explorer".

Le mostrará qué índices son necesarios.

Los índices se crean en base a CRUD y no en la tabla por sí solo.

Answer 5

En términos generales, los índices se aumentar la velocidad de las consultas, pero disminución velocidad de insertar/actualizar y aumentar el espacio de disco/cabezas. Entonces, preguntar si debe indexar cada combinación de columnas es como preguntar si debería optimizar cada función en su código. Puede hacer que algunas cosas sean más rápidas, o apenas puede ayudar, y podría doler más de lo que ayuda.

La eficacia de los índices depende de:

• Porcentaje de SELECTs frente a las inserciones y actualizaciones
• Los detalles de las consultas SELECT, y si usar combinaciones
• Tamaño de la tabla que se está indexada
• RAM y velocidad del procesador
• Configuración de MySQL para la cantidad de RAM que se va a utilizar, etc.

Por lo tanto, es difícil dar una respuesta general. El consejo de sonido básico sería: Agregue índices si las consultas son demasiado lentas. Y recuerde usar EXPLAIN para ver qué índices agregar. Tenga en cuenta que esto es similar a la versión de la base de datos del consejo general: perfile su aplicación antes de dedicar tiempo a la optimización.

Answer 6

¡Crear índices cuidadosamente! Sugiero que recopile estadísticas de consultas y decida qué columna se usa con más frecuencia durante la búsqueda para que pueda crear un índice agrupado en esta columna en particular (de todos modos cuando está creando índices en múltiples columnas, los datos físicos solo pueden ordenarse por una sola columna)

También tenga en cuenta que el índice agrupado podría disminuir significativamente el rendimiento de las consultas UPDATE/INSERT/DELETE porque provoca el reordenamiento físico de datos.