Autor: fanili, ingenieros de desarrollo de antecedentes de Tencent WXG
¡Conócelo, sepa por qué! Este artículo presenta la estructura de datos del índice, los algoritmos de búsqueda, los conceptos comunes del índice y los escenarios de falla del índice.
¿Qué es un índice?
En una base de datos relacional, un índice es una estructura de almacenamiento física única que ordena los valores de una o más columnas en una tabla de base de datos. Es una colección de uno o más valores de columna en una tabla y una tabla de señalamiento correspondiente. Una lista de punteros lógicos en la página de datos que identifican físicamente estos valores. La función del índice es equivalente a la del catálogo de libros, puede encontrar rápidamente el contenido que necesita según el número de página del catálogo. (Enciclopedia de Baidu)
El propósito del índice es mejorar la eficiencia de la búsqueda, ordenar el conjunto de valores de la tabla de datos y almacenarlo de acuerdo con una determinada estructura de datos.
Este artículo comenzará con un caso y resumirá el conocimiento del índice en términos de estructura de datos de índice, clasificación, conceptos clave y cómo usar el índice para mejorar la eficiencia de búsqueda.
Empiece con un caso
fenómeno
Existe una declaración SQL histórica existente en el negocio que hará que el servidor de base de datos se sobrecargue cuando esté en ejecución, lo que provocará que el servicio relacionado se bloquee y no se pueda completar a tiempo. La curva de supervisión de la CPU es la siguiente:
A partir de la curva de uso de CPU de la base de datos, se puede ver que la operación comercial ha estado en un estado "sub-saludable" (1) y pueden ocurrir problemas en cualquier momento a medida que la empresa crece. Este tipo de problema (2) apareció en la madrugada del 11 de noviembre, cuando la CPU de la base de datos había estado al 100% de carga alta y había muchas declaraciones de consulta lentas. Finalmente, el negocio se restaura eliminando el proceso para reducir la carga de la base de datos y reduciendo el proceso empresarial (3).
En la tarde del 11 de noviembre, se optimizó la declaración SQL del negocio y el efecto de optimización fue el siguiente. La tasa máxima de uso de la CPU durante la operación comercial se ha reducido considerablemente (en comparación con 1, 2 y 3 en la Figura 2); las declaraciones de consultas lentas son casi invisibles en la curva de monitoreo (en comparación con 1, 2 y 3 en la Figura 3) ).
análisis
Estructura de la tabla
CREATE TABLE T_Mch******Stat (`FStatDate` int unsigned NOT NULL DEFAULT 19700101 COMMENT '统计日期',
`FMerchantId` bigint unsigned NOT NULL DEFAULT 0 COMMENT '商户ID',
`FVersion` int unsigned NOT NULL DEFAULT 0 COMMENT '数据版本号',
`FBatch` bigint unsigned NOT NULL DEFAULT 0 COMMENT '统计批次',
`FTradeAmount` bigint NOT NULL DEFAULT 0 COMMENT '交易金额'
PRIMARY KEY (`FStatDate`,`FMerchantId`,`FVersion`),
INDEX i_FStatDate_FVersion (`FStatDate`,`FVersion`))
DEFAULT CHARSET = utf8 ENGINE = InnoDB;
A partir de la declaración de construcción de la tabla, podemos saber que la tabla tiene dos índices:
El índice de clave principal es un índice compuesto que consta de los campos FStateDate, FMerchantId y FVersion;
El índice ordinario es un índice combinado, compuesto por los campos FStateDate y FVersion;
Declaración SQL antes de la optimización (parcialmente recortada) A:
SELECT SQL_CALC_FOUND_ROWS FStatDate,
FMerchantId,
FVersion,
FBatch,
FTradeAmount,
FTradeCount
FROM T_Mch******Stat_1020
WHERE FStatDate = 20201020
AND FVersion = 0
AND FMerchantId > 0
ORDER BY FMerchantId ASC LIMIT 0, 8000
Explique el SQL para obtener los siguientes resultados: El valor del campo Extra usa where, lo que indica que no se usa el índice.
Sentencia SQL optimizada (parcialmente recortada) B:
SELECT SQL_CALC_FOUND_ROWS a1.FStatDate,
a1.FMerchantId,
a1.FVersion,
FBatch,
FTradeAmount,
FTradeCount
FROM T_Mch******Stat_1020 a1, (
SELECT FStatDate, FMerchantId, FVersion
FROM T_Mch******Stat_1020
WHERE FStatDate = 20201020
AND FVersion = 0
AND FMerchantId > 0
ORDER BY FMerchantId ASC LIMIT 0, 8000 ) a2
where a1.FStatDate = a2.FStatDate
and a1.FVersion = a2.FVersion
and a1.FMerchantId = a2.FMerchantId;
Los pasos clave de la optimización son:
Agregue una nueva subconsulta, el campo de selección solo tiene el campo de clave principal;
El resultado de explicación del SQL es el siguiente: la subconsulta utiliza un índice y el resultado final de la operación en línea también demuestra que el efecto de optimización es significativo.
duda
La declaración SQL optimizada B es mucho más complicada que la declaración SQL original A (subconsultas, asociaciones de tablas temporales, etc.) ¿Cómo se puede mejorar la eficiencia, contrariamente a la intuición? Hay tres preguntas:
Los campos de condición de consulta de la instrucción SQL A están todos en la clave principal, ¿se utilizan los índices de clave principal?
¿Por qué la subconsulta de la instrucción B de SQL puede usar un índice?
¿Cuál es la diferencia en el flujo de ejecución de las dos declaraciones antes y después?
Estructura de datos del índice
En MySQL, los índices se implementan en la capa del motor de almacenamiento y los diferentes motores de almacenamiento tienen diferentes métodos de implementación de acuerdo con las características de sus escenarios comerciales. Aquí primero presentaremos nuestras matrices ordenadas comunes, hashes y árboles de búsqueda, y finalmente veremos los árboles B + compatibles con el motor de Innodb.
Matriz ordenada
Array es una estructura de datos importante que se introducirá en cualquier libro sobre estructuras de datos y algoritmos. La matriz ordenada tiene su significado literal, los datos se almacenan en la matriz en orden ascendente de clave. Muy adecuado para consultas equivalentes y consultas de rango.
| ID: 1 | Identificación: 2 | ...... | ID: N |
|---|---|---|---|
| nombre2 | nombre2 | ...... | nameN |
En el caso de que el valor de ID no se repita, la matriz anterior se almacena en orden ascendente de ID. En este momento, si necesita consultar el nombre de un valor de ID específico, puede obtenerlo rápidamente usando la dicotomía, y la complejidad del tiempo es O (logn).
// 二分查找递归实现方式
int binary_search(const int arr[], int start, int end, int key)
{
if (start > end)
return -1;
int mid = start + (end - start) / 2;
if (arr[mid] > key)
return binary_search(arr, start, mid - 1, key);
else if (arr[mid] < key)
return binary_search(arr, mid + 1, end, key);
else
return mid;
}
Las ventajas de las matrices ordenadas son obvias, al igual que sus desventajas. Solo es adecuado para datos estáticos. Si los datos se insertan recientemente, se requerirá el movimiento de datos (acciones como solicitar un nuevo espacio, copiar datos y liberar espacio), lo que consumirá recursos.
Picadillo
Una tabla hash es una estructura que almacena datos en clave-valor (KV). Solo necesitamos ingresar la clave K para encontrar el valor correspondiente V. La idea del hash es usar una función hash específica para convertir K a una posición en la matriz y luego colocar el valor V en esta posición en la matriz. Si encuentra diferentes K y calcula la misma posición, extraiga una lista enlazada en esta posición y almacénelos en secuencia. Las tablas hash son adecuadas para escenarios de consulta equivalentes, mientras que las consultas de rango correspondientes son incapaces.
Árbol de búsqueda binaria
El árbol de búsqueda binaria, también conocido como árbol de búsqueda binario, árbol binario ordenado o árbol binario ordenado, se refiere a un árbol vacío o un árbol binario con las siguientes propiedades:
Si el subárbol izquierdo de cualquier nodo no está vacío, los valores de todos los nodos del subárbol izquierdo son menores que el valor de su nodo raíz;
Si el subárbol derecho de cualquier nodo no está vacío, los valores de todos los nodos en el subárbol derecho son mayores o iguales que el valor de su nodo raíz;
Los subárboles izquierdo y derecho de cualquier nodo también son árboles de búsqueda binarios, respectivamente;
La ventaja del árbol de búsqueda binaria en comparación con otras estructuras de datos es que la complejidad temporal de la búsqueda y la inserción es menor, que es O (logn). Para mantener la complejidad de la consulta O (logn), el árbol debe ser un árbol binario equilibrado.
Algoritmo de búsqueda del árbol de búsqueda binaria:
Si b es un árbol vacío, la búsqueda falla, de lo contrario:
Si x es igual al valor del nodo raíz de b, la búsqueda es exitosa; de lo contrario:
Si x es menor que el valor del nodo raíz de b, busque en el subárbol izquierdo; de lo contrario:
Encuentra el subárbol correcto.
En comparación con las matrices ordenadas y Hash, los árboles de búsqueda binarios funcionan muy bien en ambos extremos de la búsqueda y la inserción. Sobre la base de esta optimización continua, se desarrolló el árbol N-ario y así sucesivamente.
Árbol B +
El motor de almacenamiento Innodb admite el índice de árbol B +, el índice de texto completo y el índice hash. El índice hash admitido por el motor de almacenamiento Innodb es adaptativo, y el motor de almacenamiento Innodb genera automáticamente un índice hash para la tabla de acuerdo con el uso de la tabla, sin intervención humana. El índice del árbol B + es el índice más común en las bases de datos relacionales, y también será el protagonista de este artículo.
estructura de datos
En el artículo anterior, presenté brevemente las matrices ordenadas y los árboles de búsqueda binaria, y tengo un conocimiento básico de la búsqueda binaria y los árboles binarios. La definición de árbol B + es relativamente complicada, no es necesario profundizar para comprender el mecanismo de trabajo de la indexación, solo para comprender el formulario de organización de datos y el algoritmo de búsqueda. Simplemente podemos pensar en el árbol B + como una combinación de árbol N-ario y matriz ordenada.
P.ej:
3 ventajas del árbol B +:
Nivel más bajo, menos IO veces
Los nodos hoja deben consultarse cada vez y el rendimiento de la consulta es estable
Los nodos de hoja forman una lista enlazada ordenada, y la consulta de rango es conveniente
Algoritmo de operación
Encontrar
El árbol se recorre de arriba a abajo desde el nodo raíz y el puntero del lado que se buscará de acuerdo con el valor de separación; la búsqueda binaria se utiliza para determinar la posición dentro del nodo.
insertar
Eliminar
Nota: El contenido de las dos tablas de inserción y eliminación es de "MySQL Technical Insider-InnoDB Storage Engine"
Factor de relleno (innodb_fill_factor): el porcentaje de espacio en cada página del árbol B que se llena durante la construcción del índice y el espacio restante se reserva para el crecimiento futuro del índice. Se puede ver en las operaciones de inserción y eliminación que el valor del factor de relleno afectará la frecuencia de división y fusión de la página de datos. Establecer un valor más pequeño puede reducir la frecuencia de división y fusión, pero el índice ocupará más espacio en el disco; por el contrario, aumentará la frecuencia de división y fusión, pero puede reducir el espacio en disco ocupado. Innodb reserva 1/16 del espacio para índices agrupados de forma predeterminada para garantizar la posterior inserción y actualización del índice.
Innodb B + índice de árbol
El artículo anterior presentó la estructura de datos básica del índice. Desde la perspectiva de Innodb, ahora entendemos cómo usar el árbol B + para construir un índice, cómo funciona el índice y cómo usar el índice para mejorar la eficiencia de búsqueda.
Índice agrupado e índice no agrupado
El índice del árbol B + en la base de datos se puede dividir en índice agrupado e índice no agrupado. La diferencia entre un índice agrupado y un índice no agrupado es si el nodo hoja es una fila completa de datos.
La tabla del motor de almacenamiento Innodb es una tabla organizada por índices, es decir, los datos de la tabla se almacenan en el orden de la clave principal. El índice agrupado consiste en construir un árbol B + de acuerdo con la clave principal de cada tabla, y los nodos hoja almacenan los registros de filas completos de la tabla. El nodo hoja de un índice no agrupado no contiene todos los datos del registro de fila. El contenido del nodo hoja del índice no agrupado del motor de almacenamiento Innodb es el valor del índice de clave principal.
¿Cómo crear un índice agrupado si la tabla de datos no tiene una clave principal? Cuando no hay una clave principal, Innodb generará un campo RowId de 6 bytes para cada registro de la tabla de datos y creará un índice agrupado basado en esto.
Seleccionar declaración para encontrar el proceso de registro
El siguiente ejemplo mostrará la organización de los datos de índice y el proceso de consulta de datos mediante la instrucción Select.
Declaración de construcción de mesa:
create table T (
ID int primary key,
k int NOT NULL DEFAULT 0,
s varchar(16) NOT NULL DEFAULT '',
index k(k)
) engine=InnoDB DEFAULT CHARSET=utf8;
insert into T values(100, 1, 'aa'),(200, 2, 'bb'),(300, 3, 'cc'),(500, 5, 'ee'),(600,6,'ff'),(700,7,'gg');
Diagrama de estructura de índice
A la izquierda está el índice agrupado establecido por el ID de la clave primaria, y sus nodos hoja almacenan información completa del registro de la tabla; a la derecha está el índice ordinario establecido por el campo común K, y el valor del nodo hoja es el ID de la clave principal.
Seleccionar proceso de ejecución de declaraciones
select * from T where k between 3 and 5;
El proceso de ejecución es el siguiente:
Encuentre el registro de k = 3 en el árbol de índice K y obtenga ID = 300;
Luego, vaya al árbol de índice de ID para encontrar R3 correspondiente a ID = 300;
Tome el siguiente valor k = 5 en el árbol de índice k y obtenga ID = 500;
Vuelva al árbol de índice de ID y busque R4 correspondiente a ID = 500;
Tome el siguiente valor k = 6 en el árbol de índice k Si no se cumple la condición, el ciclo termina.
Se introduce un concepto importante en el proceso anterior de búsqueda de registros: volver a la tabla , es decir, volver al proceso de búsqueda en el árbol de índice de clave primaria. Evitar operaciones back-to-table es una idea convencional y un método importante para mejorar la eficiencia de las consultas SQL. Entonces, ¿cómo evitar volver a la mesa?
Nota: este ejemplo proviene de "45 conferencias sobre combate real de MySQL"
Índice de cobertura
MySQL 5.7, declaración de construcción de tablas:
CREATE TABLE `employees` (
`emp_no` int(11) NOT NULL,
`birth_date` date NOT NULL,
`first_name` varchar(14) NOT NULL,
`last_name` varchar(16) NOT NULL,
`gender` enum('M','F') NOT NULL,
`hire_date` date NOT NULL,
PRIMARY KEY (`emp_no`),
KEY `i_first_name` (`first_name`),
KEY `i_hire_date` (`hire_date`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Instrucción SQL A
explain select * from employees where hire_date > '1990-01-14';
explicar resultado:
Instrucción SQL B
explain select emp_no from employees where hire_date > '1990-01-14';
explicar resultado:
análisis
A partir de los resultados de las dos explicaciones, podemos ver que el extra de la instrucción SQL A está usando where, y el extra de la instrucción SQL B está usando where; using index. Esto muestra que A no usa un índice y B usa un índice.
El índice K contiene el valor del ID de campo requerido por la declaración de consulta, y no es necesario volver al árbol de índice de clave principal para encontrarlo nuevamente, es decir, "cubrir" nuestros requisitos de consulta, lo que llamamos índice de cobertura. La cobertura de índices puede reducir el número de búsquedas de árboles y mejorar significativamente el rendimiento de las consultas.
Coincidencia más a la izquierda
Instrucción SQL A
explain select * from employees where hire_date > '1990-01-14' and first_name like '%Hi%';
Instrucción SQL B
explain select * from employees where hire_date > '1990-01-14' and first_name like 'Hi%';
análisis
La instrucción SQL A en la prueba anterior usa un método extremo: first_name como '% Hi%', agregando coincidencia aproximada antes y después de hacer que la instrucción SQL no pueda usar el índice; cuando se elimina el '%' más a la izquierda, la instrucción SQL B usa el índice . La coincidencia más a la izquierda pueden ser los N caracteres más a la izquierda del índice de cadena, o el campo M más a la izquierda del índice conjunto. La planificación adecuada y el uso de la coincidencia más a la izquierda pueden reducir los índices y, por lo tanto, ahorrar espacio en disco.
Índice de empuje hacia abajo
¿Qué es el índice de empuje hacia abajo? Comencemos con el siguiente conjunto de pruebas comparativas, que ejecutarán la misma declaración SQL en MySQL 5.5 y MySQL 5.7:
select * from employees where hire_date > '1990-01-14' and first_name like 'Hi%';
Ejecute explicar en MySQL 5.5, el valor del campo adicional muestra que no se usa ningún índice
Se necesitan 0,12 segundos para ejecutar la consulta
Ejecute Explique en MySQL 5.7, el valor del campo adicional muestra que se usa la inserción de índice
Se necesitan 0.02s para ejecutar la consulta
Índice de empuje hacia abajo
El valor del campo adicional en el resultado de la explicación contiene la condición de índice de uso, lo que indica que se usa la inserción de índice. La función de inserción de índice es compatible desde la versión 5.6. Antes de la versión 5.6, el índice i_first_name no se usaba. Debe ir a la tabla de índice de clave primaria cada vez para obtener el valor de registro completo para comparar. A partir de la versión 5.6, debido a la existencia del índice i_first_name, el valor de first_name del índice se puede usar directamente para el filtrado, de modo que los registros que no cumplen la condición "first_name like'Hi% '" no necesitan volver a la tabla.
Optimización MRR
La versión 5.6 de MySQL comenzó a admitir la optimización de lectura de rango múltiple (MRR). El propósito de la optimización de MRR es reducir el acceso aleatorio a los discos y convertir el acceso aleatorio en un acceso a datos más secuencial. Puede generar declaraciones de consulta SQL vinculadas a IO. El rendimiento ha mejorado enormemente. Primero echemos un vistazo a la prueba de comparación. Las siguientes declaraciones de prueba se ejecutan bajo la misma instancia de MySQL y el servicio MySQL se reinicia antes de la ejecución para garantizar que la caché no se caliente.
Apague MRR
SET @@optimizer_switch='mrr=off';
select * from employees where hire_date > '1990-01-14' and first_name like 'Hi%';
El tiempo de ejecución es inferior a 0,90 s.
Encienda MRR
SET @@optimizer_switch='mrr=on,mrr_cost_based=off';
select * from employees where hire_date > '1990-01-14' and first_name like 'Hi%';
análisis
A partir de los resultados de la prueba, se puede encontrar que cuando mrr está activado, el consumo de tiempo se reduce de 0,90 sa 0,03 s, y la tasa de consulta se incrementa 30 veces.
Escenarios comunes de falla de índice
Una vez que se establece un índice en una tabla MySQL, ¿la instrucción de consulta SQL utilizará necesariamente el índice? No necesariamente, hay escenarios en los que el índice falla. Agregamos un índice compuesto a la tabla de empleados, y los ejemplos posteriores se basan en esta tabla para análisis y pruebas.
alter table employees add index i_b_f_l(birth_date, first_name, last_name)
alter table employees add index i_h(hire_date);
Escenario de falla
Consulta de rango (>, <, <>)
explain select * from employees where hire_date > '1989-06-02';
Tipos de condiciones de consulta incoherentes
alter table employees add index i_first_name (first_name);
explain select * from employees where first_name = 1;
La condición de consulta usa una función
explain select * from employees where CHAR_LENGTH(hire_date) = 10;
Consulta difusa
explain select * from employees where hire_date like '%1995';
No utilice el primer campo del índice compuesto como condición
explain select * from employees where last_name = 'Kalloufi' and first_name = 'Saniya';
¿Por qué falla?
La lectura secuencial es mejor que el rendimiento de lectura discreta
¿La consulta de rango definitivamente hará que el índice falle?
¡No! Cambie ligeramente las condiciones de la consulta y observe el resultado de la comparación de Explicar. Puede ver que la nueva declaración utiliza la inserción de índice, lo que indica que el índice no es válido. ¿por qué?
En el caso de no utilizar un índice de cobertura, el optimizador solo elegirá utilizar un índice no agrupado cuando la cantidad de datos sea pequeña. Restringido por las características de los discos mecánicos tradicionales, el rendimiento de la lectura de filas de datos secuencialmente a través de un índice agrupado es mejor que la lectura de filas de datos discretamente a través de un índice no agrupado. Por lo tanto, el optimizador elegirá un índice agrupado incluso si hay un índice no agrupado, pero la cantidad de datos a los que se accede puede llegar al 20% del número de registros enviados. Por supuesto, Force index también se puede utilizar para forzar el índice.
explain select * from employees where hire_date > '1999-06-02';
No se puede usar el índice B + para buscar rápidamente
El elemento básico del índice de árbol B + que admite consultas rápidas es porque sus valores de clave de índice se almacenan de manera ordenada, de pequeños a grandes de izquierda a derecha, de modo que pueda verificar rápidamente en cada nivel de nodos e ingresar al siguiente nivel, y finalmente El nodo hoja encuentra el valor correspondiente.
El uso de funciones hará que MySQL no pueda usar el índice para consultas rápidas, porque la operación de la función en el campo de índice destruirá el orden del valor del índice, por lo que el optimizador elige no usar el índice. El tipo de condición de consulta inconsistente es en realidad el mismo, porque usa conversión de tipo implícita *.
La coincidencia aproximada y el hecho de no utilizar el primer campo del índice combinado como condición de la consulta no pueden localizar rápidamente la posición del índice, lo que provoca la imposibilidad de utilizar el índice. Coincidencia aproximada Cuando la condición de la consulta es donde A ike'a% 'y a es el prefijo más a la izquierda de A, es posible utilizar el índice (coincidencia más a la izquierda). Si se usa o no, depende de la evaluación del optimizador del volumen de datos de la consulta.
Volver al caso original
Volvamos al caso al principio del artículo e intentemos responder las 3 preguntas planteadas en ese momento.
-- A语句
SELECT FStatDate, FMerchantId, FVersion, FBatch, FTradeAmount, FTradeCount FROM T_Mch******Stat_1020 WHERE FStatDate = 20201020 AND FVersion = 0 AND FMerchantId > 0 ORDER BY FMerchantId ASC LIMIT 0, 8000;
-- B语句
SELECT SQL_CALC_FOUND_ROWS a1.FStatDate,
a1.FMerchantId,
a1.FVersion,
FBatch,
FTradeAmount,
FTradeCount
FROM T_Mch******Stat_1020 a1, (
SELECT FStatDate, FMerchantId, FVersion
FROM T_Mch******Stat_1020
WHERE FStatDate = 20201020
AND FVersion = 0
AND FMerchantId > 0
ORDER BY FMerchantId ASC LIMIT 0, 8000 ) a2
where a1.FStatDate = a2.FStatDate
and a1.FVersion = a2.FVersion
and a1.FMerchantId = a2.FMerchantId;
Los campos de condición de consulta de la instrucción SQL A están todos en la clave principal, ¿se utilizan los índices de clave principal?
El índice de clave principal se utiliza realmente: la consulta de rango del índice solo necesita leer y analizar todos los registros uno por uno para provocar una consulta lenta.
¿Por qué la subconsulta de la instrucción B de SQL puede usar un índice?
En el artículo anterior, presentamos un índice agrupado, el valor de la clave del índice es la clave principal.
La diferencia entre las dos sentencias SQL es que el campo Seleccionar de la sentencia de subconsulta de la sentencia B se incluye en el campo de clave principal, mientras que la sentencia A tiene otros campos (como FBatch y FTradeAmount, etc.). En este caso, solo el valor de clave del índice de clave principal puede cumplir con los requisitos de campo de la declaración B; la declaración A necesita tomar la fila completa de registros uno por uno para su análisis.
¿Cuál es la diferencia en el flujo de ejecución de las dos declaraciones antes y después?
El proceso de ejecución de la declaración SQL A:
Escanee la tabla de índice una por una y compare las condiciones de la consulta
Leer toda la fila de datos y devolver si cumple con las condiciones de la consulta
Vuelva al paso a hasta que se complete la comparación de todos los registros de índice
Ordene todos los registros devueltos (registros completos) que cumplan con los criterios
Seleccione los primeros 8000 datos para devolver
El proceso de ejecución de la declaración SQL B:
Escanee la tabla de índice una por una y compare las condiciones de la consulta
Si cumple con las condiciones de la consulta, tome el valor del campo relevante de la clave de índice y regrese
Vuelva al paso a hasta que se complete la comparación de todos los registros de índice
Ordene todos los registros devueltos que cumplan con las condiciones (cada registro tiene solo 3 claves primarias)
Seleccione los primeros 8000 datos para volver a formar una tabla temporal
Asocie la tabla temporal con la tabla principal, use la comparación de igualdad de clave primaria para consultar 8000 datos
Al comparar el proceso de ejecución de las dos sentencias SQL, se puede encontrar que las diferencias se concentran en los pasos 2 y 4. En el paso 2, la instrucción A de SQL necesita leer aleatoriamente toda la fila de datos y el análisis requiere muchos recursos; el paso 4 involucra el algoritmo de clasificación de MySQL, que también afectará la eficiencia de ejecución. En términos del efecto de clasificación, la instrucción B de SQL es mejor que la instrucción A.
Glosario
Índice de clave primaria
Como sugiere el nombre, este tipo de índice se compone de la clave principal de la tabla, ordenada de pequeña a grande de izquierda a derecha. Una tabla de almacenamiento Innodb tiene solo una tabla de índice de clave principal (índice agrupado).
Índice normal
El tipo de índice más común, no existe ninguna restricción especial.
Índice único
Los campos del índice no pueden tener el mismo valor, pero se permiten valores nulos.
Índice compuesto
Los índices compuestos por varios campos de columna a menudo se establecen para mejorar la eficiencia de las consultas.
para resumir
Al comienzo del artículo, se introducen varias estructuras de datos de índice comunes, como matrices ordenadas adecuadas para datos estáticos, índices hash adecuados para estructuras KV y árboles binarios de búsqueda que tienen en cuenta el rendimiento de la consulta y la inserción; luego, presentan el método de implementación de índice común de Innodb árbol B + Y la instrucción Select usa el índice de árbol B + para encontrar el proceso de ejecución del registro. En esta parte, comprendemos varios conceptos clave, volviendo a la tabla, índice de cobertura, coincidencia más a la izquierda, empuje de índice hacia abajo y MMR; después de eso, también resumimos los escenarios de falla del índice y La razón detrás. Finalmente, volvemos al caso original y analizamos la diferencia en el uso de índices en sentencias SQL antes y después de la optimización, lo que conduce a diferencias en la eficiencia de ejecución.
Este artículo presenta algunos conocimientos superficiales del índice, con la esperanza de ayudar un poco a los lectores. Como resumen del aprendizaje por fases, el conocimiento del artículo sobre el índice MySQL es básicamente superficial, y debe usarse y estudiarse en profundidad en el futuro.
¿Cómo aliviar las preocupaciones? Solo aprendiendo.
Bibliografía e información
Segunda edición de "MySQL Storage Engine Inside -InnoDB", autor: Jiangcheng Yao
"MySQL 45 combate el estrés", autor: Lin Xiaobin
https://dev.mysql.com/doc/refman/8.0/en/
https://zh.wikipedia.org/wiki/%E4%BA%8C%E5%85%83%E6%90%9C%E5%B0%8B%E6%A8%B9
https://github.com/zhangyachen/zhangyachen.github.io/issues/117