MySQL: ¿por qué no indexar todos los campos?


107

Recientemente, aprendí la maravilla de los índices y el rendimiento ha mejorado drásticamente. Sin embargo, con todo lo que he aprendido, parece que no puedo encontrar la respuesta a esta pregunta.

Los índices son geniales, pero ¿por qué alguien no podría simplemente indexar todos los campos para hacer que la tabla sea increíblemente rápida? Estoy seguro de que hay una buena razón para no hacer esto, pero ¿qué tal tres campos en una tabla de treinta campos? ¿10 en un campo de 30? ¿Dónde se debe trazar la línea y por qué?


7
intente insertar un valor en una tabla con más de 10k entradas indexadas, todas las entradas deben actualizarse debido a las inserciones / eliminaciones y esto es una gran sobrecarga de tiempo y algo de memoria si cada valor tiene un índice
Jesús Ramos

5
Hay una razón más además del espacio y el rendimiento de escritura: usar múltiples índices para un acceso a una sola tabla es muy ineficiente . Eso significa que, incluso si tiene un índice en cada columna, el rendimiento de selección no es muy bueno si se accede a varias columnas en la cláusula WHERE. En ese caso, lo mejor es un índice de varias columnas.
Markus Winand

1
si tiene una tabla con 30 campos, realmente debería mirar las estructuras de su tabla. Debería ser muy difícil trabajar con ellos.
webs

Respuestas:


122

Los índices ocupan espacio en la memoria (RAM); Demasiados o demasiado grandes índices y la base de datos tendrá que intercambiarlos hacia y desde el disco. También aumentan el tiempo de inserción y eliminación (cada índice debe actualizarse para cada dato insertado / eliminado / actualizado).

No tienes memoria infinita. Haciendo que todos los índices quepan en RAM = bueno.

No tienes tiempo infinito. Indexar solo las columnas que necesita indexar minimiza el impacto de rendimiento de inserción / eliminación / actualización.


11
Buena respuesta informal para brindar una comprensión general, pero no ayuda mucho para determinar realmente dónde trazar la línea en los índices. ¿Cómo puedes saberlo? Simplemente agréguelos a los campos comúnmente WHERED y espere lo mejor.
Andrew

@Andrew un año y medio después, ¿encontraste la respuesta a tu pregunta?
Sinjai

1
@Sinjai Probablemente, agregarlos a las columnas donde se encuentran comúnmente es una buena regla general. Pero, de lo contrario, podría leer mucho si quiere convertirse en un experto en índices. p.ej. stackoverflow.com/questions/3049283/…
Andrew

No olvide el espacio en disco.
jpmc26

27

Tenga en cuenta que cada índice debe actualizarse cada vez que se actualiza, inserta o elimina una fila. Por lo tanto, cuantos más índices tenga, menor rendimiento tendrá para las operaciones de escritura.

Además, cada índice ocupa más espacio en disco y espacio de memoria (cuando se llama), por lo que también podría ralentizar las operaciones de lectura (para tablas grandes). Mira esto


6
El enlace es para MS SQL Server ; esta pregunta es para MySQL
OMG Ponies

5
@OMG la mayoría de los puntos en el enlace se aplican a todos los RDBMS principales
RichardTheKiwi

5
@Richard también conocido como cyberkiwi: ANSI no cubre los índices; es un milagro que cada proveedor haya utilizado una terminología similar. Pero incluso entonces, solo SQL Server y MySQL usan la terminología de índice "agrupado" y "no agrupado"; significa más en SQL Server que en MySQL. No hay nada que garantice que las recomendaciones de un proveedor se apliquen a otro.
OMG Ponies

3
@omg los primeros 6 puntos se aplican a cualquier dbms. omita los no / agrupados, a continuación, más abajo hay más puntos sobre la indexación general, también en el punto. Si tienes cosas específicas que quieras señalar, llámalos. De lo contrario, parece que está negando todas las respuestas que, según los comentarios (incluida su respuesta eliminada), nadie está de acuerdo con su evaluación.
RichardTheKiwi

10

Tienes que equilibrar las necesidades de CRUD. Escribir en tablas se vuelve lento. En cuanto a dónde trazar la línea, eso depende de cómo se acceda a los datos (filtrado de clasificación, etc.).


y también cada índice ocupa algo de espacio en la base de datos
Acanthus

@Acanthus: Los discos duros más pequeños disponibles se miden en gigabytes .
OMG Ponies

4
@OMG pero no RAM como señala Brian. Nunca es una buena idea almacenar más de lo necesario. el almacenamiento en caché de datos / índices en la RAM, los medios de respaldo (versiones que se ajustan a cada cinta, etc.) se ven afectados por índices inútiles
RichardTheKiwi

9
La abundancia de un recurso no es motivo de desperdicio o ineficiencia.
Smandoli

6
Es cierto, pero las limitaciones no son las que eran hace más de 10 años.
OMG Ponies

2

La indexación ocupará más espacio asignado tanto de la unidad como de la memoria RAM, pero también mejorará mucho el rendimiento. Desafortunadamente, cuando alcanza el límite de memoria, el sistema cederá el espacio de la unidad y arriesgará el rendimiento. Prácticamente, no debe indexar ningún campo que pueda pensar que no está involucrado en ningún tipo de algoritmo de desplazamiento de datos, ni inserción ni búsqueda (cláusula WHERE). Pero deberías hacerlo si no. De forma predeterminada, debe indexar todos los campos. Los campos que debe considerar desindexar es si las consultas son utilizadas solo por el moderador, a menos que también necesiten velocidad.


2

esta respuesta se basa en mi opinión personal Estoy usando mi lógica matemática para responder

la segunda pregunta fue sobre el borde donde detenerse, primero hagamos un cálculo matemático, supongamos que tenemos N filas con L campos en una tabla si indexamos todos los campos obtendremos una L nuevas tablas de índice donde cada tabla se ordenará en un De manera significativa los datos del campo de índice, a primera vista, si su tabla tiene un peso W, se convertirá en W * 2 (1 tera se convertirá en 2 tera) si tiene una tabla grande de 100 (ya trabajé en el proyecto donde estaba el número de la tabla alrededor de 1800 mesa) desperdiciará 100 veces este espacio (100 tera), esto está lejos de ser prudente.

Si aplicaremos índices en todas las tablas, tendremos que pensar en las actualizaciones de índices, si una actualización desencadena la actualización de todos los índices, esta es una selección de todos los equivalentes desordenados en el tiempo.

de esto concluyo que tienes en este escenario que si pierdes este tiempo es preferible perderlo en una selección ni en una actualización porque si seleccionas un campo que no está indexado no dispararás otra selección en todos los campos que estén no indexado

que indexar?

claves externas: es una necesidad basada en

clave primaria: todavía no estoy seguro de que puede ser que alguien lea esto pueda ayudar en este caso

otros campos: la primera respuesta natural es la mitad de los campos restantes por qué: si debe indexar más, no está lejos de la mejor respuesta, si debe indexar menos, tampoco está lejos porque sabemos que ningún índice es malo y todo indexado también es malo.

A partir de estos 3 puntos, puedo concluir que si tenemos campos L compuestos por teclas K, el límite debería estar en algún lugar cercano ((L-K)/2)+Kmás o menos en L / 10

esta respuesta se basa en mi lógica y mis precios personales


1

No es una buena idea indexar todas las columnas de una tabla. Si bien esto hará que la tabla sea muy rápida de leer, también será mucho más lento escribir en ella. Escribir en una tabla que tiene todas las columnas indexadas implicaría poner el nuevo registro en esa tabla y luego poner la información de cada columna en su propia tabla de índice.


No estoy seguro de si haría que la lectura de la tabla fuera increíblemente rápida, especialmente si la tabla de datos es solo de 100 MB pero la tabla indexada de 300 MB o más.
David

Todo lo que dijiste se ha dicho antes.
Vael Victus
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.