115 Índice

Una introducción

¿Por qué hay un índice?

En los sistemas de aplicaciones generales, la relación de lectura y escritura es de aproximadamente 10: 1, y las operaciones de inserción y las operaciones de actualización generales rara vez tienen problemas de rendimiento. En el entorno de producción, encontramos los más y los más propensos a problemas, o algunos Operación de consulta, por lo que la optimización de la declaración de consulta es obviamente la máxima prioridad. Hablando de consultas aceleradas, hay que mencionar los índices.

¿Qué es un índice?

Los índices también se denominan "claves" en MySQL y son 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 una tabla aumenta cada vez más, el impacto de los índices en el rendimiento se vuelve cada vez más importante.
La optimización de índices debería ser el medio más eficaz para optimizar el rendimiento de las consultas. Los índices pueden mejorar fácilmente el rendimiento de las consultas en varios órdenes de magnitud.
El índice es equivalente a la tabla de secuencia de un diccionario. Si desea buscar una palabra, si no usa la tabla de secuencia, debe buscarla página por página de cientos de páginas.

¿Tiene un malentendido sobre el índice?

La indexación es un aspecto importante del diseño y desarrollo de aplicaciones. Si hay demasiados índices, el rendimiento de la aplicación puede verse afectado. Muy pocos índices tendrán un impacto en el rendimiento de la consulta. Para encontrar un punto de equilibrio, esto es crucial para el rendimiento de la aplicación. Algunos desarrolladores siempre piensan en agregar índices después del hecho; siempre pienso que esto se debe a un modelo de desarrollo incorrecto. Si conoce el uso de los datos, debe agregar índices donde sea necesario desde el principio. Los desarrolladores a menudo usan la base de datos a nivel de aplicación, como escribir declaraciones SQL, procedimientos almacenados, etc., es posible que ni siquiera conozcan la existencia del índice o piensen que el DBA relevante puede agregarlo después. Los administradores de bases de datos a menudo no saben lo suficiente sobre el flujo de datos de la empresa y, al agregar índices, es necesario monitorear una gran cantidad de declaraciones SQL para encontrar problemas. El tiempo requerido para este paso debe ser mucho mayor que el tiempo requerido para agregar inicialmente índices, y es posible que se pierdan algunos índices. Por supuesto, el índice no es tantos como sea posible. Me he encontrado con un problema de este tipo: un iostat del servidor MySQL muestra que el uso del disco ha sido del 100%. Después del análisis, se encontró que el desarrollador agregó demasiados índices y los eliminó. Después de algunos índices innecesarios, el uso del disco se redujo inmediatamente al 20%. Se puede ver que la adición del índice también es muy técnica.

El principio de dos índices

Un principio de índice

El propósito de la indexación es mejorar la eficiencia de las consultas, que es el mismo que el catálogo que usamos para buscar libros: primero ubique el capítulo, luego ubique una sección debajo del capítulo y luego encuentre el número de páginas. Ejemplos similares incluyen: buscar en el diccionario, buscar números de tren, vuelos de avión, etc.

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

La base de datos es la misma, pero obviamente más complicada, porque no solo se enfrenta a consultas equivalentes, sino también consultas de rango (>, <, entre, en), consultas difusas (como), consultas de unión (o), etc. ¿Qué forma debería elegir la base de datos para abordar todos los problemas? Pensemos en el ejemplo del diccionario. ¿Podemos dividir los datos en segmentos y consultarlos en segmentos? La más simple es si hay 1000 datos, de 1 a 100 se dividen en el primer párrafo, de 101 a 200 se dividen en el segundo párrafo y de 201 a 300 se dividen en el tercer párrafo ... De esta manera, para verificar el dato número 250, solo necesita encontrar el tercer párrafo. Se eliminó el 90% de los datos no válidos. Pero si son 10 millones de registros, ¿cuántos segmentos es mejor? Los estudiantes con un poco de base algorítmica pensarán en árboles de búsqueda, cuya complejidad promedio es lgN, que tiene un buen rendimiento de consulta. Pero aquí ignoramos un tema clave: el modelo de complejidad se basa en el mismo costo operativo en todo momento. La implementación de la base de datos es más complicada. Por un lado, los datos se almacenan en el disco. Por otro lado, para mejorar el rendimiento, parte de los datos se pueden leer en la memoria para su cálculo cada vez, porque sabemos que el costo de acceder al disco es de alrededor de 100.000 de la memoria. Por lo tanto, el árbol de búsqueda simple es difícil de cumplir con los escenarios de aplicación complejos.

E / S de dos discos y lectura anticipada

El acceso al disco se mencionó anteriormente, por lo que aquí hay una breve introducción a la E / S del disco y la lectura previa. El disco lee datos mediante un movimiento mecánico. El tiempo dedicado a leer datos cada vez se puede dividir en tiempo de búsqueda, retardo de rotación y tiempo de transmisión. En parte, el tiempo de búsqueda se refiere al tiempo necesario para que el brazo magnético se mueva a la pista especificada. El disco principal generalmente está por debajo de 5 ms; el retraso de rotación es la velocidad del disco que escuchamos con frecuencia. Por ejemplo, un disco tiene 7200 revoluciones, lo que significa 7200 revoluciones por minuto. , Lo que significa que puede girar 120 veces por segundo, y el retraso de rotación es 1/120/2 = 4.17ms; el tiempo de transmisión se refiere al tiempo para leer del disco o escribir datos en el disco, generalmente en unas pocas décimas de milisegundo, en relación con Las dos primeras veces se pueden ignorar. Entonces, el tiempo para acceder a un disco, es decir, el tiempo de una E / S de disco es de aproximadamente 5 + 4,17 = 9 ms, lo que suena bastante bien, pero debe saber que una máquina de 500 MIPS (millones de instrucciones por segundo) puede ejecutar 5 por segundo. Cientos de millones de instrucciones, porque las instrucciones dependen de la naturaleza de la electricidad, en otras palabras, se pueden ejecutar alrededor de 4,5 millones de instrucciones en un tiempo de ejecución de E / S, y la base de datos puede ejecutar fácilmente 100.000 millones o incluso decenas de millones de datos. Cada vez que 9 milisegundos es obviamente una desastre. La siguiente figura es un cuadro comparativo de los retrasos del hardware de la computadora para su referencia:

Considerando que la E / S del disco es una operación muy costosa, el sistema operativo de la computadora ha realizado algunas optimizaciones. Los datos también se leen en el búfer de memoria, porque el principio de lectura anticipada parcial nos dice que cuando la computadora accede a los datos de una dirección, también se accederá rápidamente a los datos adyacentes. Los datos leídos por cada IO se denominan página. La cantidad de datos en una página específica está relacionada con el sistema operativo, generalmente 4k u 8k, es decir, cuando leemos los datos en una página, realmente ocurre un IO. Esta teoría es muy útil para el diseño de la estructura de datos del índice.

Estructura de datos de tres índices

Hablé sobre los principios básicos de la indexación, la complejidad de la base de datos y el conocimiento relacionado del sistema operativo. El propósito es que todos sepan que ninguna estructura de datos se crea de la nada. Deben existir sus antecedentes y escenarios de uso. Ahora, para resumir, lo que necesitamos que haga esta estructura de datos es realmente muy simple, es decir: cada vez que busque datos, controle el número de E / S de disco en un pequeño orden de magnitud, preferiblemente un orden de magnitud constante. Entonces pensamos si un árbol de búsqueda multidireccional altamente controlable podría satisfacer la demanda. De esta manera, nació el árbol b + (el árbol B + es un árbol de búsqueda binario y luego evolucionó a partir de un árbol binario equilibrado, árbol B).

Como se muestra en la figura anterior, es un árbol b +. Para la definición de árbol b +, consulte el árbol B +. A continuación, se muestran algunos puntos importantes. El bloque azul claro se llama bloque de disco. Puede ver que cada bloque de disco contiene varios elementos de datos. (Se muestra en azul oscuro) y punteros (se muestra en amarillo). Por ejemplo, el bloque de disco 1 contiene elementos de datos 17 y 35, incluidos los punteros P1, P2 y P3. P1 representa bloques de disco menores que 17 y P2 representa elementos de datos entre 17 y 35. Bloque de disco, P3 significa bloque de disco mayor de 35. Los datos reales existen en los nodos hoja, a saber, 3, 5, 9, 10, 13, 15, 28, 29, 36, 60, 75, 79, 90, 99. Los nodos que no son hojas solo almacenan datos reales, solo elementos de datos que guían la dirección de búsqueda. Por ejemplo, 17 y 35 no existen realmente en la tabla de datos.

b + proceso de búsqueda de árbol

Como se muestra en la figura, si desea encontrar el elemento de datos 29, primero cargue el bloque de disco 1 desde el disco a la memoria. En este momento, se produce una E / S. Utilice la búsqueda binaria para determinar que 29 está entre 17 y 35 en la memoria y bloquee el bloque de disco 1. El tiempo de memoria del puntero P2 es muy corto (en comparación con el IO del disco) y se puede ignorar. El bloque de disco 3 se carga desde el disco a la memoria a través de la dirección de disco del puntero P2 del bloque de disco 1, y ocurre el segundo IO, 29 en 26 y Entre 30, bloquee el puntero P2 del bloque de disco 3, cargue el bloque de disco 8 en la memoria a través del puntero y se produce una tercera E / S. Al mismo tiempo, se realiza una búsqueda binaria en la memoria para encontrar 29 y se finaliza la consulta, un total de tres E / S. La situación real es que un árbol b + de 3 capas puede representar millones de datos. Si millones de búsquedas de datos solo requieren tres IO, la mejora del rendimiento será enorme. Si no hay índice, cada elemento de datos tendrá un IO Entonces se requieren un total de millones de IO, lo que obviamente es muy caro.

b + naturaleza del árbol

1. El campo de índice debe ser lo más pequeño posible: a
través del análisis anterior, sabemos que el número de IO depende de la altura de b + número h. Suponiendo que los datos de la tabla de datos actual son N y el número de elementos de datos en cada bloque de disco es m, entonces hay h = ㏒ (m + 1) N, cuando la cantidad de datos N es constante, cuanto mayor es m, menor es h; ym = el tamaño del bloque de disco / el tamaño del elemento de datos, el tamaño del bloque de disco es el tamaño de una página de datos , Es fijo, si el espacio ocupado por el elemento de datos es menor, el número de elementos de datos es mayor y la altura del árbol es menor. Por eso, cada elemento de datos, es decir, el campo de índice, debe ser lo más pequeño posible, por ejemplo, int ocupa 4 bytes, que es la mitad menos que bigint8 bytes. Es por eso que el árbol b + requiere que los datos reales se coloquen en los nodos hoja en lugar de en los nodos internos. Una vez colocados en los nodos internos, los elementos de datos del bloque de disco caerán significativamente, lo que conducirá a la altura del árbol. Cuando el elemento de datos es igual a 1, degenerará en una tabla lineal.

2. La característica de coincidencia más a la izquierda del índice:
cuando el elemento de datos del árbol b + es una estructura de datos compuesta, como (nombre, edad, sexo), el número b + se usa para construir el árbol de búsqueda en el orden de izquierda a derecha, como cuando (Zhang San, 20, F) Al buscar esos datos, el árbol b + primero comparará el nombre para determinar la siguiente dirección de búsqueda. Si el nombre es el mismo, luego compare la edad y el sexo por turnos, y finalmente obtendrá los datos recuperados; pero cuando ( 20, F) Cuando llegan tales datos sin nombre, el árbol b + no sabe qué nodo verificar a continuación, porque el nombre es el primer factor de comparación al construir el árbol de búsqueda, y primero debe buscar por nombre para conocer el siguiente. Dónde facturar en un solo paso. Por ejemplo, al buscar datos como (Zhang San, F), el árbol b + puede usar el nombre para especificar la dirección de búsqueda, pero falta la siguiente edad del campo, por lo que solo puede encontrar los datos con el nombre igual a Zhang San y luego hacer coincidir el género. Son los datos de F. Esta es una propiedad muy importante, es decir, la característica de coincidencia más a la izquierda del índice.

Cuatro índices agrupados e índices auxiliares

En la base de datos, la altura del árbol B + generalmente está en el _{nivel 24, lo que significa que solo se necesitan de 2 a 4 IO como máximo para encontrar el registro de fila de un determinado valor de clave, lo cual no está nada mal. Debido a que el disco duro mecánico general actual puede hacer al menos 100 IO veces por segundo, 24} IO veces significa que el tiempo de consulta solo necesita 0.02 ~ 0.04 segundos.

El índice del árbol B + en la base de datos se puede dividir en índice agrupado (índice agrupado) e índice secundario (índice secundario),

El índice agrupado es el mismo que el índice auxiliar: ya sea un índice agrupado o un índice auxiliar, su interno tiene la forma de un árbol B +, es decir, la altura está equilibrada y los nodos hoja almacenan todos los datos.

La diferencia entre un índice agrupado y un índice auxiliar es: si el nodo hoja almacena una fila completa de información

1, el índice agrupado

El motor de almacenamiento #InnoDB representa una tabla organizada por índices, es decir, los datos de la tabla se almacenan en el orden de la clave principal. El índice agrupado (índice agrupado) construye un árbol B + de acuerdo con la clave principal de cada tabla, y los nodos hoja almacenan los datos de registro de filas de toda la tabla, y los nodos hoja del índice agrupado también se denominan páginas de datos. Esta característica del índice agrupado determina que los datos de la tabla organizada por índice también forman parte del índice. Al igual que la estructura de datos del árbol B +, cada página de datos está vinculada a través de una lista doblemente vinculada.

#Si la clave principal no está definida, MySQL toma el primer índice único (único) y solo contiene columnas no vacías (NO NULL) como clave principal, e InnoDB lo usa como índice agrupado.

#Si no existe tal columna, InnoDB generará dicho valor de ID por sí mismo. Tiene seis bytes y está oculto, lo que lo convierte en un índice agrupado.

# Debido a que las páginas de datos reales solo se pueden ordenar de acuerdo con un árbol B +, cada tabla solo puede tener un índice agrupado. En muchos casos, el optimizador de consultas tiende a utilizar un índice agrupado. Porque el índice agrupado puede encontrar datos directamente en los nodos hoja del índice del árbol B +. Además, debido a que el orden lógico de los datos está definido, se puede acceder al índice agrupado de manera particularmente rápida para consultas de rango digno.

Uno de los beneficios del índice agrupado: ordena la búsqueda de clave primaria y la velocidad de búsqueda de rango es muy rápida, los datos del nodo hoja son los datos que el usuario desea consultar. Si el usuario necesita buscar una tabla y consultar la información de los últimos 10 usuarios, debido a que el índice del árbol B + es una lista doblemente vinculada, el usuario puede encontrar rápidamente la última página de datos y recuperar 10 registros

El segundo beneficio del índice agrupado: consulta de rango, es decir, si desea encontrar datos en un cierto rango de la clave principal, puede obtener el rango de página a través del nodo intermedio superior del nodo hoja y luego leer la página de datos directamente

2. Índice auxiliar

A excepción del índice agrupado, los otros índices de la tabla son índices secundarios (índice secundario, también conocido como índice no agrupado). La diferencia con el índice agrupado es que el nodo hoja del índice secundario no contiene todos los datos del registro de fila.

Además del valor clave del nodo hoja, la fila de índice de cada nodo hoja también contiene un marcador. Este marcador se utiliza para indicarle al motor de almacenamiento InnoDB dónde encontrar los datos de fila correspondientes al índice.

Dado que el motor de almacenamiento InnoDB es una tabla organizada por índices, el marcador del índice auxiliar del motor de almacenamiento InnoDB es la clave de índice agrupado de la fila de datos correspondiente. Como se muestra en la figura siguiente

, la existencia de índices auxiliares no afecta la organización de los datos en el índice agrupado, por lo que puede haber varios índices auxiliares en cada tabla, pero solo puede haber un índice agrupado. Al buscar datos a través del índice auxiliar, el motor de almacenamiento InnoDB atraviesa el índice auxiliar y obtiene la clave principal que solo quiere el índice de clave principal a través del puntero de nivel de hoja, y luego encuentra un registro de fila completo a través del índice de clave principal.

Por ejemplo, si busca datos en un árbol de índice auxiliar con una altura de 3, debe recorrer el árbol de índice auxiliar 3 veces para encontrar la clave principal especificada. Si la altura del árbol de índice agrupado también es 3, entonces también debe realizar el árbol de índice agrupado Después de 3 búsquedas, finalmente se encuentra una página donde se encuentra una fila completa de datos, por lo que se requieren un total de 6 accesos IO lógicos para obtener la página de datos final.

Cinco gestión de índices MySQL

Una función

# 1. La función del índice es acelerar la búsqueda.
# 2. La clave principal, única y única conjunta en mysql también son índices. Además de acelerar la búsqueda, estos índices también tienen la función de restricción

Dos índices de MySQL de uso común

普通索引INDEX：加速查找

唯一索引：
    -主键索引PRIMARY KEY：加速查找+约束（不为空、不能重复）
    -唯一索引UNIQUE:加速查找+约束（不能重复）

联合索引：
    -PRIMARY KEY(id,name):联合主键索引
    -UNIQUE(id,name):联合唯一索引
    -INDEX(id,name):联合普通索引

Los dos tipos de tres índices, hash y btree

# Podemos especificar el tipo de índice para el índice anterior al crear el índice anterior. Hay dos tipos de
índices de tipo hash: la consulta única es rápida y la consulta de rango es lenta.
Índice de tipo Btree: b + árbol, cuantas más capas, el crecimiento exponencial del volumen de datos ( Lo usamos, porque innodb lo admite por defecto)

# Diferentes motores de almacenamiento admiten diferentes tipos de índices.
InnoDB admite transacciones, bloqueo a nivel de fila, admite árbol B, texto completo y otros índices, pero no admite índice Hash;
MyISAM no admite transacciones, admite bloqueo a nivel de tabla, admite B- Índices como el árbol y el texto completo no admiten el índice Hash; la
memoria no admite transacciones, bloqueo a nivel de tabla, árbol B, Hash y otros índices, pero no admite índice de texto completo;
NDB admite transacciones, bloqueo a nivel de fila y Hash Índice, no admite árbol B, texto completo y otros índices; el
archivo no admite transacciones, admite bloqueo a nivel de tabla y no admite árbol B, Hash, texto completo y otros índices;

Cuatro crear / eliminar sintaxis de índice

#方法一：创建表时
    　　CREATE TABLE 表名 (
                字段名1  数据类型 [完整性约束条件…],
                字段名2  数据类型 [完整性约束条件…],
                [UNIQUE | FULLTEXT | SPATIAL ]   INDEX | KEY
                [索引名]  (字段名[(长度)]  [ASC |DESC]) 
                );

#方法二：CREATE在已存在的表上创建索引
        CREATE  [UNIQUE | FULLTEXT | SPATIAL ]  INDEX  索引名 
                     ON 表名 (字段名[(长度)]  [ASC |DESC]) ;


#方法三：ALTER TABLE在已存在的表上创建索引
        ALTER TABLE 表名 ADD  [UNIQUE | FULLTEXT | SPATIAL ] INDEX
                             索引名 (字段名[(长度)]  [ASC |DESC]) ;
                             
#删除索引：DROP INDEX 索引名 ON 表名字;

Índice de seis pruebas

Una preparación

Velocidad de consulta de dos pruebas sin índice

# Sin índice: MySQL no sabe si hay un registro con id igual a 333333333. Solo puede escanear la tabla de datos de principio a fin. En este momento, cuántos bloques de disco deben realizarse como tantas operaciones IO, por lo que la velocidad de consulta es muy lenta
mysql> seleccione * de s1 donde id = 333333333;
Conjunto vacío (0,33 seg)
Tres, bajo la premisa de que hay una gran cantidad de datos en la tabla, indexar un determinado segmento de campo será muy lento.

En cuarto lugar, una vez creado el índice, cuando el campo se utiliza como condición de consulta, la velocidad de consulta aumenta significativamente
PS:

1. mysql primero va a la tabla de índice de acuerdo con el principio de búsqueda del árbol b + y rápidamente encuentra que el registro con id igual a 333333333 no existe, y el IO se reduce considerablemente, por lo que la velocidad mejora significativamente.

2. Podemos ir al directorio de datos de mysql para encontrar la tabla, podemos ver que ocupa más espacio en el disco duro

Cinco resumen
# 1. Debe ser para crear un índice para el campo de condición de búsqueda, como seleccionar * de s1 donde id = 333; necesitas agregar un índice al id

# 2. En el caso de una gran cantidad de datos en la tabla, la construcción del índice será muy lenta y ocupará espacio en el disco duro. Después de completar la consulta, la velocidad de la consulta aumentará. Por
ejemplo, cree el índice idx en s1 (id); escaneará todos los datos en la tabla, y luego Utilice id como un elemento de datos para crear una estructura de índice y almacenarlo en una tabla en el disco duro.
Una vez completada, la consulta será rápida.

# 3. Cabe señalar que el índice de la tabla innodb se almacenará en el archivo s1.ibd, y el índice de la tabla myisam tendrá un archivo de índice separado table1.MYI

El archivo de índice MySAM y el archivo de datos están separados, y el archivo de índice solo guarda la dirección del registro de datos. En innodb, el archivo de datos de la tabla en sí es una estructura de índice organizada de acuerdo con B + Tree (BTree es Balance True), y el campo de datos del nodo hoja de este árbol guarda registros de datos completos. La clave de este índice es la clave principal de la tabla de datos, por lo que el propio archivo de datos de la tabla innodb es el índice principal.
Debido a que los archivos de datos de inndob se agregan de acuerdo con la clave principal, innodb requiere que la tabla tenga una clave principal (Myisam puede que no). Si no hay una definición explícita, el sistema mysql seleccionará automáticamente una columna que pueda identificar de forma única el registro de datos como la clave principal. Si no existe Para este tipo de columna, mysql generará automáticamente un campo implícito como clave principal para la tabla innodb. La longitud de este campo es de 6 bytes y el tipo es un entero largo.

Para obtener resultados de índices, índices de cobertura e índices conjuntos, consulte:
https://www.cnblogs.com/linhaifeng/articles/7274563.html#_label7