[Serie MySQL] -¿Realmente comprende el retorno de la tabla y el índice de cobertura?

[Serie MySQL] -¿Realmente comprende el retorno de la tabla y el índice de cobertura?

A menudo me hacen algunas preguntas conceptuales durante las entrevistas. En realidad, estos contenidos se utilizan menos en el desarrollo, pero debes aprenderlos para mostrar tu reserva de conocimientos. Los blogueros suelen encontrar este problema al realizar recientemente el examen de certificación de MySQL. Recopile conceptos de MySQL y genere esta publicación de blog.

1. Estructura del índice MYSQL

1.1 El concepto de índice

La definición oficial de índice de MYSQL es: Índice (Índice) es una estructura de datos que ayuda a MySQL a mejorar la adquisición de datos. La esencia de un índice es una estructura de datos. Puede entenderse simplemente como "predisponer un conjunto de estructuras de datos que puedan consultarse rápidamente". Estas estructuras de datos apuntan a los datos de alguna manera y se pueden implementar algoritmos de consulta avanzados a través de estas estructuras de datos.

1.2 Características del índice

1. Indexar una estructura de datos ordenada puede acelerar la recuperación de la base de datos.
2. Los índices reducen la dificultad de las tareas de mantenimiento de bases de datos como Insertar, Actualizar y Eliminar.
3. Los índices MySQL solo se pueden crear en tablas, no en vistas.
4. El procesador de consultas ejecuta sentencias SQL. Sólo se puede utilizar un índice en una tabla a la vez.

1.3 Ventajas de la indexación

1. Mejore la eficiencia de la recuperación de datos y reduzca los costos de E/S de la base de datos
2. Cree un índice único para garantizar la unicidad de cada fila de datos en la tabla de la base de datos.
3. Acelere tablas y uniones entre tablas.
4. Al utilizar cláusulas de agrupación y clasificación para la recuperación de datos, puede reducir significativamente el tiempo dedicado a agrupar y ordenar las consultas.

1.4 Desventajas de los índices

1. Crear y mantener índices lleva tiempo y este tiempo aumenta con la cantidad de datos.
2. Los índices deben ocupar espacio físico. Además del espacio de datos que ocupa la tabla de datos, cada índice también ocupa una cierta cantidad de espacio físico. Si se va a establecer un índice agrupado, el espacio requerido será mayor.
3. Al agregar, eliminar y modificar datos en la tabla, el índice debe mantenerse dinámicamente, lo que reduce la velocidad de mantenimiento de los datos.

2. Árbol B y Árbol B+

2.1 Árbol B

B-Tree es un árbol B. B-tree es un árbol autoequilibrado que puede mantener los datos en orden. Esta estructura de datos permite que la consulta de datos, el acceso secuencial, la inserción y eliminación de datos se completen en tiempo logarítmico. En términos generales, el número B es un árbol de búsqueda binario generalizado que puede tener más de 2 nodos secundarios. A diferencia de los árboles de búsqueda binarios autoequilibrados, los árboles B están optimizados para leer y escribir grandes cantidades de datos en el sistema. B-tree reduce el proceso intermedio que se experimenta al localizar registros, acelerando así el acceso. B-tree es una estructura de datos que se puede utilizar para describir el almacenamiento externo.

2.2 Árbol B+

B+Tree es una optimización de B-Tree. En el nodo solo se almacenan valores clave, no datos. Este diseño puede almacenar más valores clave y punteros en el espacio de nodo limitado (espacio de página). Todos los datos se almacenan en nodos hoja y hay punteros de enlace (listas circulares bidireccionales) entre todos los nodos hoja, lo que facilita la consulta y clasificación de rangos.

2.3 La diferencia entre B-Tree y B+Tree

1. En B-Tree, todos los nodos tendrán punteros a registros específicos; en B+Tree, solo los nodos hoja tendrán punteros a registros específicos.
2. Las diferentes hojas en B-Tree no están conectadas entre sí; todos los nodos de hojas en B+Tree están conectados entre sí mediante punteros.
3. En B-Tree, el puntero a un registro específico se puede obtener de un nodo no hoja y la eficiencia de la búsqueda es inestable; en B+Tree, el puntero a un registro específico se debe obtener de un nodo hoja y la búsqueda la eficiencia es estable.

En B+Tree, dado que los nodos que no son hoja no tienen punteros a registros específicos, se pueden almacenar más elementos de índice en nodos que no son hoja, lo que puede reducir efectivamente la altura del árbol y mejorar la eficiencia de la búsqueda.

En B+Tree, los nodos de hoja están conectados entre sí mediante punteros, por lo que si es necesario realizar un escaneo de rango, será muy fácil de implementar. Sin embargo, para B-Tree, el escaneo de rango requiere escanear constantemente los nodos de hoja y los nodos que no son de hoja. .Moverse entre puntos.

2.4 Entonces, ¿por qué es mejor que las claves principales de InnoDB estén en orden?

El índice de clave principal en InnoDB es un índice agrupado y todos los datos se almacenan en los nodos hoja de la estructura de árbol B + del índice agrupado donde se encuentra el índice de clave principal. Si el tamaño de la clave primaria insertada cada vez es aleatorio, la ubicación de los nodos hoja encontrados cada vez que ingresan los datos será aleatoria. En este caso, las páginas donde se encuentran algunos nodos hoja ya están llenas y como resultado , viene otro dato, lo que inevitablemente provocará cambios en la página. La división provocará una degradación del rendimiento, pero si la clave principal está en orden, la posición delante de la hoja actual se encontrará cada vez y las hojas se llenarán Suba una página y luego otra página en orden, por lo que no habrá problemas de división de páginas. Por lo tanto, las claves primarias de incremento automático tienen un mejor rendimiento para motores de almacenamiento como InnoDB que utilizan índices B+Tree.

3. Consulta de tabla de retorno

La consulta de retorno de tabla significa que MySQL requiere dos consultas internas durante el proceso de consulta de datos. Primero ubique el valor de la clave principal de la tabla donde se encuentran los datos de la consulta y luego ubique el registro de fila según la clave principal.

Para comprender la consulta de tabla, primero debemos comenzar con la implementación del índice de InnoDB. Los índices de InnoDB se dividen en dos categorías: índice agrupado e índice secundario.

3.1 Índice agrupado de InnoDB

Un índice agrupado es un índice en el que la estructura del índice y los datos se almacenan juntos. El índice de clave principal es un índice agrupado.

Los nodos hoja del índice agrupado de InnoDB almacenan registros de filas, por lo que InnoDB debe tener uno y solo un índice agrupado.

1. Si la tabla define una PK (Clave primaria, clave primaria), entonces la PK es un índice agrupado;
2. Si la tabla no define una PK, la primera columna NOT NULL UNIQUE es el índice agrupado.
3. De lo contrario, InnoDB creará un ROWID oculto adicional como índice agrupado.

Dado que este mecanismo localiza directamente registros de fila, hace que las consultas basadas en PK sean muy rápidas.

3.2 Índice no agrupado de InnoDB

Un índice no agrupado es un índice en el que la estructura del índice y los datos existen por separado. El índice auxiliar es un índice no agrupado.

Los nodos hoja del índice no agrupado no necesariamente almacenan punteros a los datos (los nodos hoja del índice auxiliar almacenan la clave principal y luego consultan los datos en la tabla según la clave principal).

3.3 Horario de InnoDB

Volver a consultar la tabla significa primero consultar la clave primaria correspondiente a través del índice no agrupado y luego consultar el valor correspondiente a través del índice de clave primaria. Repase el índice B+Tree dos veces.

4. Índice de cobertura

Si ejecuta una declaración de consulta para obtener directamente el valor a consultar sin pasar por dos consultas B + Tree, no es necesario devolver la tabla en este momento, es decir, en esta consulta, el índice "cubre" el consulta Esto se llama índice de cobertura.

Debido a que los índices de cobertura reducen la cantidad de búsquedas de B+Tree y mejoran el rendimiento de las consultas, el uso de índices de cobertura es un método de indexación común. La forma más común de utilizar un índice de cobertura es crear un índice conjunto y colocar todos los campos que deben consultarse en el índice conjunto.

Utilice explique sql. Si se utiliza un índice en Extra, demuestra que se utiliza un índice de cobertura.

5. El principio del prefijo más a la izquierda

El prefijo más a la izquierda utiliza el índice para acelerar la recuperación. El prefijo más a la izquierda puede ser los N campos más a la izquierda del índice conjunto o los M caracteres más a la izquierda del índice de cadena. Es decir, si desea consultar N campos, son incluido en un determinado Dentro de los N campos más a la izquierda del índice conjunto, en pocas palabras, los datos en los campos del índice deben estar para lograr este tipo de búsqueda y utilizar el índice.

Resumen del principio del prefijo más a la izquierda

1. Supongamos que hay tres campos (col1, col2, col3), MySQL puede admitir índices conjuntos de (col1), (col1, col2) y (col1, col2, col3).
2. La pregunta más controvertida (col1, col3) es si admite la indexación conjunta, que se admite en los documentos oficiales y también en nuestros experimentos.
3. Cambiar el orden de varias condiciones de búsqueda en la cláusula donde no afectará los resultados de la consulta, porque hay un optimizador de consultas en Mysql que optimizará automáticamente el orden de las consultas.
4. En la cláusula Where, si encuentra una consulta de rango (> <entre, me gusta) o un par de índices no creado en el Resumen 1, dejará de coincidir (la consulta de rango encontrada aún participa en el índice).

6. Fallo del índice

Una vez creado el índice, algún SQL incorrecto provocará que el índice falle. Existen varios escenarios que provocarán que el índice falle.

1. Si hay OR en las condiciones de consulta, incluso si algunas de las condiciones están indexadas, no serán válidas;
2. La consulta LIKE ya comienza con %;
3. Si el tipo de columna es una cadena, los datos deben citarse entre comillas en las condiciones de consulta; de lo contrario, no se utilizará el índice;
4. Participar en cálculos en columnas de índice provocará fallas en el índice;
5. Viola el principio de coincidencia más a la izquierda;
6. Si Mysql estima que un escaneo completo de la tabla es más rápido que usar un índice, no se usará el índice.
7. El índice del árbol B no irá si es nulo, pero sí irá si no es nulo.El índice de mapa de bits irá si es nulo y irá si no es nulo;
8. El índice conjunto no es nulo se utilizará siempre que se creen las columnas del índice (sin ningún orden en particular). Cuando esté en nulo, debe usarse con la primera columna del índice. Cuando la primera condición de posición del índice es es nulo, otras columnas indexadas Puede ser nulo (pero debe serlo cuando todas las columnas satisfacen que es nulo), o = un valor; cuando la primera posición del índice es = un valor, otras columnas del índice pueden ser cualquier situación (incluyendo es null = un valor), el índice desaparecerá en ambos casos. No se irá en otras circunstancias.

7. Empujar el índice hacia abajo

El pushdown de condición de índice (pushdown de condición de índice), conocido como ICP, se lanzó en MySQL 5.6 y versiones posteriores para optimizar las consultas de retorno de tablas; cuando no se usa ICP, se usan índices de clave no primaria (también llamados índices ordinarios o índices secundarios). ) al realizar la consulta, el motor de almacenamiento recupera los datos a través del índice y luego los devuelve al servidor MySQL, el servidor luego determina si los datos cumplen con las condiciones, en el caso de usar ICP, si existen ciertas condiciones para las columnas indexadas. , el servidor MySQL pasará esta parte de la condición de juicio al motor de almacenamiento,
y luego el motor de almacenamiento juzgará si el índice cumple con las condiciones pasadas por el servidor MySQL. Solo cuando el índice cumpla con las condiciones se recuperarán y devolverán los datos. al servidor MySQL;

• Verificar el estado de la inserción del índice

show VARIABLES like '%optimizer_switch%';
-------------------------------------------------------
optimizer_switch	index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,engine_condition_pushdown=on,index_condition_pushdown=on,mrr=on,mrr_cost_based=on,block_nested_loop=on,batched_key_access=off,materialization=on,semijoin=on,loosescan=on,firstmatch=on,duplicateweedout=on,subquery_materialization_cost_based=on,use_index_extensions=on,condition_fanout_filter=on,derived_merge=on,use_invisible_indexes=off,skip_scan=on,hash_join=on,subquery_to_derived=off,prefer_ordering_index=on,hypergraph_optimizer=off,derived_condition_pushdown=on

• Desactivar el índice pushdown

#索引下推是mysql 5.6优化查询回表的功能，在5.6之前都不支持索引下推
set optimizer_switch='index_condition_pushdown=off';

• Habilitar inserción de índice

set optimizer_switch='index_condition_pushdown=on';

• Resumir
  1. La función de inserción de índice es una operación introducida en MySQL 5.6 para optimizar el retorno de la tabla, solo admite compatibilidad hacia arriba y no es compatible con versiones inferiores;
  2. La inserción de índice solo optimiza la cantidad de resultados de la tabla, pero la cantidad de filas escaneadas sigue siendo la misma.