Índices de MySQL: ¿cuántos son suficientes?

Question

Estoy tratando de ajustar mi servidor MySQL así que verifico mi configuración, analizo el registro de consultas lentas y simplifico mis consultas si es posible.

A veces es suficiente si estoy indexando correctamente, a veces no. He leído en algún lado (corríjanme si esto es una estupidez) que más índices de los que necesito tienen el mismo efecto, como si no tuviera ningún índice.

¿Cuántos índices son suficientes? Puede decir que depende de cientos de factores, pero tengo curiosidad acerca de cómo puedo limpiar mi mysql-slow.log lo suficiente para reducir la carga del servidor.

Además, vi algunas entradas de registro "interesantes" como este:

# Query_time: 0 Lock_time: 0 Rows_sent: 22 Rows_examined: 44 
SELECT * FROM `categories` ORDER BY `orderid` ASC; 

La tabla en cuestión contiene exactamente 22 filas, índice establecido en orderid. ¿Por qué aparece esta consulta en el registro después de todo? ¿Por qué examinar 44 filas si solo contiene 22?

Answer 1

La cantidad de indexación y la línea de hacer demasiado dependerá de muchos factores. En las tablas pequeñas, como la tabla de "categorías", generalmente no desea o no necesita un índice y, de hecho, puede perjudicar el rendimiento. La razón es que se necesita E/S (es decir, tiempo) para leer un índice y luego más E/S y tiempo para recuperar los registros asociados con las filas coincidentes. Una excepción es cuando solo consulta las columnas contenidas en el índice.

En su ejemplo, está recuperando todas las columnas y con solo 22 filas y puede ser más rápido hacer un escaneo de tabla y ordenarlas en lugar de usar el índice. El optimizador puede/debería estar haciendo esto e ignorando el índice. Si ese es el caso, entonces el índice solo está ocupando espacio sin ningún beneficio. Si se accede a su tabla de "categorías" con frecuencia, puede considerar fijarla en la memoria para que el servidor db la mantenga accesible sin tener que ir al disco todo el tiempo.

Al agregar índices, debe equilibrar el espacio en disco, el rendimiento de la consulta y el rendimiento de la actualización y la inserción en las tablas. Puede salirse con la suya con más índices en tablas que son estáticas y que no cambian mucho, a diferencia de las tablas con millones de actualizaciones por día. Comenzará a sentir los efectos del mantenimiento del índice en ese punto. Sin embargo, lo que es aceptable en su entorno es y solo puede ser determinado por usted y su organización.

Al hacer su análisis, asegúrese de generar/actualizar su tabla y las estadísticas de índice para que pueda estar seguro de cálculos precisos.

Answer 2

No hay un número mágico para el "mejor" número de índices. La regla básica es la siguiente: agregue índices para consultas que se usan con frecuencia y/o que necesitan ejecutarse rápidamente.

Tener "demasiados" índices no debería ralentizar las consultas, pero cada índice agregado agrega una pequeña cantidad de tiempo para agregar/actualizar elementos en el db (ya que también modifica los índices), y una pequeña cantidad del espacio. Sin embargo, si solo está agregando índices según sea necesario, probablemente esta no sea una gran preocupación.

Answer 3

Como regla general, debe tener índices en todas las claves primarias (no puede elegir), todas las claves foráneas y cualquier otro campo que utilice habitualmente para buscar filas.

Por ejemplo, si busco comúnmente usuarios por nombre de usuario, lo indexaría, incluso si el ID de usuario era la clave principal.

Answer 4

Cuantos índices dependen completamente de las consultas que se ejecutan, qué tipos de uniones se realizan (si las hay), el tipo de datos almacenados en la tabla y cuán grandes son las tablas (y muchos otros factores). Realmente no hay ciencia exacta para eso. La mejor herramienta en su arsenal para descubrir cómo optimizar una consulta es explain. Al usar la explicación, puede averiguar qué tipo de uniones está disminuyendo, qué claves posibles se podrían usar y qué clave (si corresponde) se usó, así como cuántas filas se examinaron para cada tabla en la combinación.

Al usar esta información puede decidir cómo codificar sus tablas y/o modificar sus consultas para hacerlas más eficientes. La sintaxis para explicar es muy simple.

EXPLAIN SELECT * FROM `categories` ORDER BY `orderid` ASC; 

Nota, explicar en realidad no ejecutar la consulta. Por lo tanto, si está utilizando esto para depurar una consulta que tarda 5 minutos en ejecutarse, la explicación seguirá siendo muy rápida.

Debe tener cuidado al agregar índices, ya que hacen que las inserciones y actualizaciones vayan más despacio y en tablas muy grandes este rendimiento puede ser notable. Especialmente si esa misma tabla se usa para muchas lecturas. Aunque agregar muchos índices generalmente no matará el rendimiento de una consulta, solo debe agregarlos como yo

Answer 5

Un índice puede acelerar una consulta SELECT, pero ralentizará INSERT/UPDATE/DELETE consultas porque ellos necesitan actualizar el índice también, no solo la fila.

Esto es solo una opinión personal (no tengo datos que lo respalden), pero creo que si hay una consulta que lleva mucho tiempo y un índice la aceleraría, ¡adelante! Los índices "Demasiados" serían si agregara índices que no servían para nada (por ejemplo, no habría consultas que acelerarían). Por ejemplo, una tontería sería colocar un índice en cada columna "solo porque".

Answer 6

Además, tenga en cuenta que MySQL utilizará un máximo de un índice por declaración (aunque si usa una combinación, también puede usar una para cada combinación). Por lo tanto, indexar solo porque es una pérdida de espacio en el disco y reducirá la velocidad de la base de datos en las escrituras. Si habitualmente utiliza una instrucción where en dos columnas, haga un índice que contenga ambas columnas, será significativamente más rápido que indexar solo una.