Cómo utilizar los índices MySQL de manera eficiente
(1) En las columnas buscadas con frecuencia, es decir, columnas que suelen aparecer en cláusulas WHERE, puede considerar agregar índices para acelerar las búsquedas.
(2) Se debe agregar un índice único a la columna que identifique de manera única el registro para mejorar la unicidad de la columna y acelerar la búsqueda de registros basados en la columna.
(3) Agregar índices a las columnas utilizadas en las conexiones internas. Es mejor agregar todos los campos utilizados en las conexiones internas, porque el optimizador de MySQL seleccionará automáticamente el orden de conexión y luego observará el uso del índice. y eliminar los índices inútiles.
(4) Agregue un índice a la columna que debe ordenarse, porque el índice en sí está organizado en orden, lo que puede evitar la clasificación de archivos. Ya sabes, la capa del servidor está ordenada en la memoria, lo que consume muchos recursos.
(5) Puede considerar implementar un índice superpuesto, es decir, crear un índice conjunto basado en todos los campos de SELECT, de modo que el motor de almacenamiento solo necesite leer el índice sin volver a consultar la tabla. lo que reduce en gran medida el acceso a la tabla de datos, mejorando enormemente el rendimiento.
(6) Para aquellas columnas que no son muy selectivas, como las columnas de género, agregar un índice no acelerará significativamente la consulta, pero el índice se convertirá en una carga para la tabla.
(7) No se deben agregar índices para columnas definidas como tipos de datos de texto, imagen y bits. Esto se debe a que estas columnas tienen una gran cantidad de datos o pocos valores.
(8) Cuando los requisitos de rendimiento de escritura son mucho mayores que los de lectura, no se deben crear índices. Las puntuaciones de escritura y las de lectura son contradictorias. Esto se debe a que el costo de mantener un árbol B+ es muy alto y escribir el índice implicará dividir la página.
(9) ¿A menudo aparecen varios campos de un índice compuesto en la cláusula Where del patrón AND al mismo tiempo? ¿Pocas o ninguna consulta de campo único? Si es así, puede crear un índice completo; de lo contrario, considere un índice de un solo campo. Esto todavía muestra que, bajo la premisa de cumplir con el rendimiento de las consultas, cuantos menos índices, mejor.
(10) Si el índice compuesto contiene más de tres campos, considere cuidadosamente la necesidad y considere reducir el número de campos compuestos.
(11) Agregue índices a las columnas utilizadas para agrupar para evitar el uso de tablas temporales.
(12) se utiliza para columnas de caracteres largos, como char, varchar, etc. Debido a que la comparación de cadenas lleva mucho tiempo, considere usar un índice de prefijo para reducir la longitud del índice, o cree un índice hash personalizado, asigne la cadena a un número entero, luego use el número entero como índice y use el valor de la cadena. como condición de filtro.
Cuando creamos un índice, podemos hacer un juicio simple basado en los siguientes principios: ¿El índice reúne registros relacionados, nunca reduce la E/S del disco y acelera la búsqueda? ¿El orden de los datos en el índice es coherente con el orden de los datos que se buscan, evitando así la clasificación a nivel de servidor? ¿Las columnas del índice contienen todas las columnas necesarias en la consulta para que se pueda anular el índice? Estas condiciones son progresivas y cuanto más satisfechas estén, mejor.
2. Los índices se han creado correctamente, aún necesitamos usarlos correctamente:
(1) ¡Se utilizan operadores! =, y las palabras clave not in, not exist, >, & lt y así sucesivamente, en resumen, cuando el conjunto de resultados es grande (también cuando la condición donde se selecciona ampliamente), a menudo hace que el motor realice un escaneo completo sin utilizando un índice. Porque si usa índices, causará muchas E/S aleatorias, lo que no vale la pena.
(2) Si las operaciones se realizan en columnas de índice, como donde substr (nombre, 1, 3) =' marca ', el motor de almacenamiento no puede determinar de manera inteligente qué índices satisfacen la ecuación, por lo que estos índices no pueden utilizarse.
(3) Cuando se usa LIKE y el carácter comodín está al frente, no se puede usar el índice.
(4) Para el índice conjunto (a, b, c), si no se usa la columna más a la izquierda, generalmente no se usa el índice. Sin embargo, por ejemplo, la operación estadística count(*), donde a > Xxx, puede utilizar índices conjuntos. Después de todo, esta operación no es una recuperación y no requiere que el índice esté completamente ordenado.
(5) Para índices federados, si una columna usa búsqueda de rango, las columnas a su derecha no se pueden usar como consultas de optimización de índice, pero debido a ICP (inserción de condición de índice), estas columnas se pueden usar como condiciones de filtrado en el motor de almacenamiento Filtrar datos en.
(6) Si hay OR en la condición, cada campo utilizado por OR debe tener un índice; de lo contrario, el índice no se puede utilizar.
(7) Si desea utilizar un índice en una consulta de unión para evitar la clasificación de archivos, todos los campos utilizados en ORDER BY en la consulta de correlación deben estar en la primera tabla (tabla impulsora).