Tabla de contenido

1. ¿Por qué existe un índice?

En los sistemas de aplicaciones generales, la relación lectura-escritura es de aproximadamente 10:1, y las operaciones de inserción y las operaciones generales de actualización rara vez causan problemas de rendimiento. En un entorno de producción, lo que encontramos con más frecuencia, y los más propensos a tener problemas, son algunos complejos operaciones de consulta, por lo que la optimización de las declaraciones de consulta es obviamente una máxima prioridad. Hablando de acelerar consultas, tenemos que mencionar los índices.

2. ¿Qué es un índice?

Un índice también se denomina "clave" en MySQL, que es una estructura de datos utilizada por el motor de almacenamiento para encontrar registros rápidamente. Los índices son fundamentales para un buen rendimiento, especialmente cuando la cantidad de datos en la tabla aumenta cada vez más, el impacto de los índices en el rendimiento se vuelve cada vez más importante. La optimización del índice debería ser el método más eficaz para optimizar el rendimiento de las consultas. Los índices pueden mejorar fácilmente el rendimiento de las consultas en órdenes de magnitud. El índice es equivalente a la secuencia fonética del diccionario, si desea buscar una determinada palabra, si no utiliza la tabla fonética, debe buscarla página por página en cientos de páginas.

3. Principio del índice

El propósito de la indexación es mejorar la eficiencia de las consultas, que es lo mismo que la tabla de contenido que usamos para consultar libros: primero ubique el capítulo, luego ubique una sección debajo del capítulo y luego busque el número de página. Ejemplos similares incluyen: buscar en un diccionario, buscar números de trenes, vuelos de avión, etc.

La esencia es: filtrar los resultados finales deseados reduciendo constantemente el alcance de los datos que desea obtener y al mismo tiempo convertir eventos aleatorios en eventos secuenciales . En otras palabras, con este mecanismo de indexación, siempre podemos usar Use el Mismo método de búsqueda para bloquear datos.

Lo mismo ocurre con la base de datos, pero obviamente es mucho más complicada, porque no solo enfrenta consultas equivalentes, sino también consultas de rango (>, <, entre, en), consultas difusas (como), consultas de unión (o), etc. . ¿Cómo debería elegir la base de datos para abordar todos los problemas? Volvamos al ejemplo del diccionario: ¿podemos dividir los datos en segmentos y luego consultarlos en segmentos? La forma más sencilla es que si hay 1000 datos, de 1 a 100 se dividen en la primera sección, de 101 a 200 se dividen en la segunda sección, de 201 a 300 se dividen en la tercera sección... De esta manera, si Busque el dato número 250, solo necesita encontrar la tercera sección, de una vez. Se eliminó el 90% de los datos no válidos. Pero si es un récord de 10 millones, ¿en cuántos segmentos debería dividirse? Según el modelo de árbol de búsqueda, su complejidad promedio es lgN, lo que tiene un buen rendimiento de consulta. Pero aquí hemos pasado por alto una cuestión clave: el modelo de complejidad se basa en el mismo coste de operación cada vez. La implementación de la base de datos es más complicada: por un lado, los datos se guardan en el disco, por otro lado, para mejorar el rendimiento, parte de los datos se pueden leer en la memoria para calcularlos cada vez, porque sabemos que El costo de acceder al disco es de aproximadamente 100.000 yuanes para acceder a la memoria. En ocasiones, un árbol de búsqueda simple es difícil de encontrar en escenarios de aplicaciones complejos.

4. Motor de almacenamiento MySQL

#查询索引
show engines;

Las características de cada motor de almacenamiento se muestran en la siguiente tabla:

Los dos motores de almacenamiento más comunes son MyISAM e InnoDB.

Características	InnoDB	mi isam	Memoria	Archivo	BDB
límite de almacenamiento	64TB	No	tener	No	No
seguridad de transacciones	apoyo				apoyo
mecanismo de bloqueo	bloqueo de fila	cerradura de mesa	cerradura de mesa	bloqueo de fila	bloqueo de página
índice de árbol B	apoyo	apoyo	apoyo		apoyo
índice hash	apoyo		apoyo
Índice de texto completo		apoyo
índice de conglomerado	apoyo
caché de datos	apoyo		apoyo
caché de índice	apoyo	apoyo	apoyo
Los datos son comprimibles.		apoyo		apoyo
uso del espacio	alto	Bajo	N / A	muy bajo	Bajo
uso de memoria	alto	Bajo	medio	Bajo	Bajo
Velocidad de inserción por lotes	Bajo	alto	alto	muy alto	alto
Admite claves externas	apoyo

5. Estructura de datos del índice

MySQL utiliza principalmente dos estructuras: índice de árbol B + e índice Hash: el motor de almacenamiento InnoDB tiene como valor predeterminado el índice de árbol B + y el motor de almacenamiento de memoria tiene como valor predeterminado el índice Hash.

En MySQL, solo el motor de almacenamiento de Memoria (las tablas de memoria solo existen en la memoria y desaparecen cuando se apaga, y son adecuadas para tablas temporales) admite índices Hash, que es el tipo de índice predeterminado para las tablas de Memoria. Las tablas de memoria también pueden usar B+Tree índices. El índice hash organiza los datos en forma hash, por lo que la búsqueda de un determinado registro es muy rápida. Pero debido a la estructura hash, cada clave solo corresponde a un valor y se distribuye en forma hash. Por lo tanto, no admite funciones como la búsqueda y clasificación de rangos. B+Tree es la estructura de datos de índice más utilizada en MySQL y es el tipo de índice de los modos de motor de almacenamiento InnoDB y MyIsam. En comparación con el índice Hash, B+Tree no es tan rápido como el índice Hash para buscar un solo registro, pero es más popular porque es más adecuado para operaciones como la clasificación. Después de todo, es imposible operar con un solo registro en la base de datos.

El árbol B+ es un árbol equilibrado de múltiples bifurcaciones. La diferencia de altura desde el nodo raíz hasta cada nodo hoja no excede 1, y existen conexiones relacionadas con punteros entre los dos nodos en el mismo nivel. Recuperación convencional en el árbol B+, desde el nodo raíz hasta La eficiencia de búsqueda de los nodos hoja es básicamente la misma y no fluctuará significativamente. Además, durante el escaneo secuencial basado en índices, también se pueden usar punteros bidireccionales para moverse rápidamente hacia la izquierda y hacia la derecha, lo cual es muy eficiente. Por lo tanto, los índices de árbol B+ se utilizan ampliamente en escenarios como bases de datos y sistemas de archivos.
El índice hash utiliza un determinado algoritmo hash para convertir el valor clave en un nuevo valor hash. Al recuperarlo, no es necesario buscar paso a paso desde el nodo raíz hasta el nodo hoja como un árbol B+. Solo se necesita un algoritmo hash para localízalo inmediatamente, llegar a la ubicación correspondiente es muy rápido.

Una comparación de los dos índices es la siguiente:

Si se trata de una consulta equivalente, entonces el índice hash obviamente tiene una ventaja absoluta, porque el valor clave correspondiente solo se puede encontrar mediante un algoritmo, siempre que todos los valores clave sean únicos. Si el valor de la clave no es único, primero debe encontrar la ubicación de la clave y luego escanear hacia atrás de acuerdo con la lista vinculada hasta encontrar los datos correspondientes.

Si se trata de una recuperación de consulta de rango, el índice hash es inútil en este momento, porque los valores clave originalmente ordenados pueden volverse discontinuos después del algoritmo hash y no hay forma de usar el índice para completar el rango Recuperación de consultas; Los índices hash no pueden usar el índice para completar la clasificación y consultas difusas parciales como me gusta; los índices hash no admiten la regla de coincidencia más a la izquierda de los índices conjuntos de varias columnas.

La eficiencia de recuperación de palabras clave del índice del árbol B+ es relativamente promedio y no fluctúa tanto como la del árbol B. Cuando hay una gran cantidad de valores clave duplicados, la eficiencia del índice hash también es extremadamente baja, por lo que hay una problema de colisión de hash.

Resumen de comparación:

Índice de tipo hash: la consulta única es rápida, la consulta de rango es lenta
Índice de tipo btree: árbol b +, cuantas más capas, la cantidad de datos aumenta exponencialmente (InnoDB lo admite de forma predeterminada)

6. Índices agrupados y no agrupados

El tipo de índice de mysql está relacionado con el motor de almacenamiento: los archivos de datos del motor de almacenamiento InnoDB y los archivos de índice se colocan en el archivo ibd, mientras que los archivos de datos de MyIsam se colocan en el archivo myd y el índice se coloca en el archivo myi. De hecho, existe una distinción entre índices agrupados e índices no agrupados que es muy simple: simplemente determine si los datos y el índice se almacenan juntos.

Cuando el motor de almacenamiento InnoDB inserta datos, los datos deben colocarse junto con el índice. Si hay una clave principal, use la clave principal. Si no hay una clave principal, use la clave única. Si no hay una clave única, use Rowid de 6 bytes. Por lo tanto, está vinculado a los datos. Juntos están el índice agrupado. Para evitar el almacenamiento de datos redundante, los nodos hoja de otros índices almacenan los valores clave del índice agrupado. Por lo tanto, hay índices agrupados e índices no agrupados en InnoDB, mientras que en MyIsam solo índices no agrupados.

7. Principios de diseño de índices

Al diseñar el índice, debe asegurarse de que el espacio ocupado por el campo del índice sea lo más pequeño posible. Esta es solo una dirección general, y hay algunos detalles a los que se debe prestar atención:

Las columnas adecuadas para la indexación son aquellas que aparecen en la cláusula donde o se especifican en la cláusula de unión.
Las tablas con cardinalidad pequeña tienen un rendimiento de índice deficiente y no es necesario crear índices.
Al seleccionar columnas de índice, cuanto más cortas mejor. Puedes especificar parte de determinadas columnas. No es necesario utilizar los valores de todos los campos.
No crees un índice para cada campo de la tabla. Cuantos más índices, mejor.
Las columnas de datos definidas con claves externas deben crear índices
No tener índices para campos actualizados con frecuencia.
No cree un índice con demasiadas columnas. Puede crear un índice compuesto, pero no se recomienda tener demasiadas columnas en el índice compuesto.
No cree índices para texto grande y objetos grandes

MySQL: explicación detallada de los índices