una tablas recomendaciones porque optimizar optimizacion lenta las dañan cuello consulta conexiones como botella agilizar mysql optimization indexing sql-delete

tablas - MySQL eliminar declaración de optimización



porque se dañan las tablas en mysql (2)

Tengo algunas consultas de eliminación para ejecutar contra una tabla bastante grande (~ 100 GB), y quiero optimizarlas tanto como sea posible:

delete from table1 where column1 < date_sub(now(), interval 100 hour);

column1 es una columna de datetime y datetime , supongo que crear un índice para esta columna acelerará las eliminaciones. Además de eso, ¿hay algo que pueda hacer aquí? ¿usará la función date_sub() ralentizará la consulta? ¿Debería calcular ese valor antes de ejecutar la consulta?

delete from table2 where column2 = x;

column2 es la clave principal para table2, por lo que ya es un índice según la documentación de mysql. mi pregunta es: el tipo de índice es PRIMARY , ¿es lo mismo que el INDEX ? ¿Tengo que hacer otro índice del índice tipo para acelerar?

delete from table3 where column3 = y;

table3 tiene una clave primaria compuesta, que es column3 y column4. entonces tengo un índice de clave principal, pero dado que la consulta de eliminación no usa la columna 4, ¿debería crear un índice separado solo para column3? o la clave primaria combinada lo haría?

Supongo que estas son preguntas bastante básicas, pero no pude encontrar una respuesta definitiva específica para mi situación, ¡así que cualquier ayuda sería apreciada!


Supongo que crear un índice para esta columna acelerará las eliminaciones.

Incorrecto, porque ese mismo índice debe actualizarse para que el índice tenga algún valor para uso futuro.

¿usará la función date_sub () ralentizará la consulta?

No, está bien porque no se basa en un valor de columna. Las funciones realizadas en los valores de columna aseguran que no se puede usar un índice, si existe uno en la columna.

el tipo de índice es "PRIMARIO", ¿es lo mismo que el "ÍNDICE"?

Lo es, y la porción principal asegura que los valores en ese índice también son únicos.

¿Tengo que hacer otro índice del tipo "ÍNDICE" para acelerar?

No, tu no. MySQL también limita el tamaño total de los índices que se pueden definir en una sola tabla, según el tipo. 767 bytes es la limitación de prefijo de índice indicada para tablas InnoDB; es 1,000 bytes para tablas MyISAM.

table3 tiene una clave primaria compuesta, que es column3 y column4. entonces tengo un índice de clave principal, pero dado que la consulta de eliminación no usa la columna 4, ¿debería crear un índice separado solo para column3? o la clave primaria combinada lo haría?

Pruebe ambas configuraciones y decida. No creo que el índice adicional sea necesario.


Si su DELETE está destinado a eliminar la gran mayoría de las filas de esa tabla, una cosa que la gente suele hacer es copiar solo las filas que desea conservar en una tabla duplicada, y luego usar DROP TABLE o TRUNCATE para borrar la tabla original mucho más rápido

Un índice puede ayudarlo a encontrar las filas que necesita eliminar, pero eliminarlo requiere actualizar el índice. Después de eliminar muchas filas, el índice puede desequilibrarse y requiere mantenimiento con OPTIMIZE TABLE .

La función DATE_SUB() es una expresión constante (no varía fila por fila) por lo que el optimizador de consultas debe ser lo suficientemente inteligente como para factorizarlo y realizar el cálculo una vez.

No es necesario crear un índice adicional para una clave principal. La restricción de clave primaria crea implícitamente un índice que ofrece el mismo beneficio que un índice de clave no primaria.

Un índice compuesto es probablemente tan útil como un índice de columna única, siempre que sus criterios de búsqueda hagan referencia a la (s) columna (s) más a la izquierda del índice. La advertencia "probable" se debe a que los nodos de índice individuales son más grandes y se necesita más memoria para almacenar en caché el índice, pero este es un factor lo suficientemente pequeño como para no crear un índice completo de una sola columna.