Comprenda el índice SQL y la optimización en diez minutos

Concepto y función de índice

La indexación es una tecnología para ordenar registros. Se puede especificar que se ordene por una determinada columna / algunas columnas de antemano, mejorando así en gran medida la velocidad de consulta (similar a la búsqueda por pinyin o trazos en un diccionario chino).

La función principal del índice es acelerar la velocidad de búsqueda de datos y mejorar el rendimiento de la base de datos.

Tipo de índice MySQL

Desde la perspectiva del almacenamiento físico, los índices se pueden dividir en índices agrupados e índices no agrupados.

 

1. Índice agrupado (índice agrupado)

El índice agrupado determina el orden físico de los datos en el disco y una tabla solo puede tener un índice agrupado.

El orden lógico de los valores clave en el índice determina el orden físico de las filas correspondientes en la tabla (la dirección de almacenamiento físico de los datos en el índice es el mismo que el orden del índice) , que puede entenderse como sigue: mientras el índice sea continuo, los datos estarán en el medio de almacenamiento. La ubicación de almacenamiento también es continua.

• Si se define una clave principal, esta clave principal se utiliza como índice agrupado
• Si no se define una clave principal, el primer índice no vacío único de la tabla se utiliza como índice agrupado.
• Si no hay una clave principal ni un índice único adecuado, innodb generará una clave principal oculta como índice agrupado. La clave principal oculta es una columna de 6 bytes y el valor de la columna modificada aumentará automáticamente a medida que se vayan registrando los datos. insertado.

El motor InnoDB agrega un índice agrupado a cada tabla, y los datos apuntados por el índice agrupado se almacenan en el orden de los discos físicos. La clave primaria autoincrementada insertará automáticamente los datos hacia atrás, evitando el índice agrupado durante el proceso de inserción. Problema de clasificación. Si se ordena el índice agrupado, esto provocará una gran pérdida de rendimiento de E / S del disco.

2. Índice no agrupado (índice no agrupado)

El índice no agrupado no determina el orden físico de los datos en el disco. El índice solo contiene los datos indexados y un localizador de filas, un localizador de filas. Este localizador de filas puede entenderse como un indicador del orden físico del índice agrupado. Este puntero puede encontrar datos de fila.

Desde un punto de vista lógico, el índice se puede dividir en las siguientes categorías.

• Índice ordinario: El índice más básico, no tiene restricciones.

• Índice único: similar a un índice normal, la diferencia es que el valor de la columna de índice debe ser único, pero se permiten valores nulos. Si es un índice compuesto, la combinación de valores de columna debe ser única.

• Índice de clave principal: es un índice único especial que se utiliza para identificar de forma única un registro en la tabla de datos. No se permiten valores nulos. Generalmente, la clave principal se utiliza para restringir. La relación entre la clave principal y el índice agrupado se detalla en la Pregunta 4 en "Solución detallada de problemas".

• Índice conjunto (también llamado índice compuesto): un índice creado en varios campos puede acelerar la recuperación de condiciones de consulta compuestas.

• Indexación de texto completo: el índice de texto completo que viene con la versión anterior de MySQL solo se puede utilizar para tablas de datos cuyo motor de base de datos es MyISAM. La nueva versión de InnoDB de MySQL 5.6 admite la indexación de texto completo. De forma predeterminada, MySQL no admite la búsqueda de texto completo en chino. Puede admitir chino ampliando MySQL, agregando la búsqueda de texto completo en chino o proporcionando una tabla de índice en inglés correspondiente para la tabla de contenido en chino.

 

Reglas de optimización de índices de MySQL

El índice MySQL se puede optimizar mediante las siguientes reglas.

1. La consulta difusa inicial no puede utilizar el índice.

Por ejemplo, la siguiente instrucción SQL no puede usar un índice.

seleccione  *  del documento  donde un  título  como  '% XX'

En lugar de realizar consultas difusas iniciales, puede utilizar índices, como la siguiente instrucción SQL.

seleccione  *  del documento  donde un  título  como  'XX%'

La búsqueda de páginas está estrictamente prohibida si se deja borrosa o totalmente borrosa, si es necesario, puede usar un motor de búsqueda para resolverla.

2. Unión, en, o todos pueden golpear el índice, se recomienda usar en.

• union: Posibilidad de golpear el índice.

El código de muestra es el siguiente:

seleccione  *  del documento  donde estado = 1

unión de todos

seleccione  *  del documento  donde estado = 2

Dígale a MySQL cómo hacerlo directamente. MySQL consume la menor cantidad de CPU, pero generalmente no está escrito así.

• en: Capaz de golpear el índice.

El código de muestra es el siguiente:

seleccione  *  del documento  donde el estado en  (1, 2)

La optimización de consultas consume más CPU que la unión total, pero se puede ignorar. En general, se recomienda usar en

• o: la nueva versión de MySQL puede llegar al índice.

El código de muestra es el siguiente:

seleccione  *  del documento  donde estado  = 1  o estado  = 2

La optimización de consultas consume más CPU que en, y no se recomienda su uso o con frecuencia.

3. Las consultas condicionales negativas no pueden utilizar índices y se pueden optimizar como en las consultas.

Las condiciones negativas incluyen:! =, <>, No está, no existe, no me gusta, etc.

Por ejemplo, el siguiente código:

seleccione  *  del documento  donde estado  ! = 1  y estado  ! = 2

Puede optimizarse en consulta:

seleccione  *  del documento  donde el estado en  (0,3,4)

4. El principio del prefijo del extremo izquierdo del índice conjunto (también llamado consulta del extremo izquierdo)

• Si se establece un índice conjunto en los tres campos (a, b, c), entonces puede acelerar la velocidad de consulta de a | (a, b) | (a, b, c).

Por ejemplo, inicie sesión en requisitos comerciales, el código es el siguiente.

seleccione uid, login_time  del usuario donde  login_name =? y passwd =?

Se puede establecer un índice conjunto de (login_name, passwd).

Debido a que casi no existe un requisito de consulta de condición única para passwd en la empresa, y existen muchos requisitos de consulta de condición única para nombre_de_segistro, se puede establecer un índice conjunto de (nombre_de_segistro, contraseña_de_seguridad) en lugar de (nombre_de_segistro).

• Al construir un índice conjunto, el campo con el mayor grado de discriminación se encuentra en el extremo izquierdo.

• Si se establece el índice conjunto (a, b), no es necesario crear un índice por separado. De la misma forma, si se establece el índice conjunto (a, b, c), no es necesario establecer por separado índices a, (a, b).

• Cuando hay condiciones de juicio mixtas de signo no igual y signo igual, coloque la columna de condición de signo igual al frente al construir el índice. Por ejemplo, donde a>? Y b = ?, incluso si a tiene un mayor grado de discriminación, b debe colocarse al frente del índice.

• El requisito de consulta más a la izquierda no significa que el orden where de la instrucción SQL deba ser coherente con el índice conjunto.

La siguiente instrucción SQL también puede golpear (nombre_de_inicio, contraseña) este índice conjunto.

seleccione uid, login_time  del usuario donde  passwd =? y login_name =?

Sin embargo, se recomienda que el orden después de donde sea el mismo que el índice de articulaciones y desarrolle un buen hábito.

5. Los índices se pueden usar para columnas de rango (el índice combinado debe ser el prefijo más a la izquierda).

• Las condiciones de rango son: <, <=,>,> =, entre, etc.

• Los índices se pueden usar para columnas de rango (el índice conjunto debe ser el prefijo más a la izquierda), pero las columnas posteriores a la columna de rango no se pueden usar para índices. El índice se puede usar como máximo para una columna de rango. Si hay dos columnas de rango en la condición de la consulta, el índice no se puede utilizar para todos.

Si hay un índice conjunto (empno, title, fromdate), entonces el emp_no en el siguiente SQL puede usar el índice, pero el título y from_date no pueden usar el índice.

seleccione  *  de employee.titles  donde  emp_no <10010 'y title =' Senior Engineer 'y from_date entre' 1986-01-01 'y' 1986-12-31 '

6. Coloque los cálculos en la capa empresarial en lugar de en la capa de la base de datos.

• Los cálculos sobre el terreno no pueden llegar al índice.

Por ejemplo, la siguiente instrucción SQL.

seleccione  *  del documento  donde  YEAR (create_time) <= '2016'

Incluso si un índice se establece en la fecha, escaneará toda la tabla, que se puede optimizar para el cálculo del valor, de la siguiente manera:

seleccione  *  del documento  donde  create_time <= '2016-01-01'

• Ponga los cálculos en la capa empresarial.

Esto no solo ahorra la CPU de la base de datos, sino que también optimiza la caché de consultas.

Por ejemplo, la siguiente declaración SQL:

seleccionar  * de  orden donde  fecha  <=  CURDATE ()

Puede optimizarse como:

seleccione  * de  orden donde  fecha  <= '2018-01-2412: 00: 00'

El SQL optimizado libera la CPU de la base de datos para múltiples llamadas, y la caché de consultas se puede usar solo si el SQL entrante es el mismo.

7. La conversión de tipo forzada escaneará toda la tabla.

Si el campo del teléfono es de tipo varchar, el siguiente SQL no puede llegar al índice.

 seleccione  *  fromuser donde  phone = 13800001234

Puede optimizarse como:

seleccione  *  fromuser donde  phone = '13800001234'

8. No es recomendable construir índices en campos que se actualizan con frecuencia y cuyos datos no son muy distinguidos.

• Las actualizaciones cambiarán el árbol B + y la indexación de los campos actualizados con frecuencia reducirá en gran medida el rendimiento de la base de datos.

• El atributo de "género" no es muy distinguible. La indexación no tiene sentido y los datos no se pueden filtrar de manera efectiva. El rendimiento es similar al de una exploración de tabla completa.

• Generalmente, el índice se puede crear cuando el grado de discriminación es superior al 80%, y el grado de discriminación se puede calcular usando count (distinto (nombre de la columna)) / count (*).

9. Utilice el índice de cobertura para realizar operaciones de consulta para evitar volver a la tabla.

Los datos de la columna consultada pueden recuperarse del índice en lugar del localizador de filas y luego recuperarse en la fila, es decir, "la columna de consulta debe estar cubierta por el índice construido", lo que puede acelerar la consulta.

Por ejemplo, inicie sesión en requisitos comerciales, el código es el siguiente.

seleccione uid, login_time  del usuario donde  login_name =? y passwd =?

Se puede establecer un índice conjunto de (login_name, passwd, login_time). Dado que login_time se ha establecido en el índice, el uid y el login_time que se consultan no necesitan ir a la fila para obtener datos, lo que acelera la consulta.

10. Si hay escenarios ordenados y agrupados por, preste atención al orden del índice.

• El último campo de orden por es parte del índice compuesto y se coloca al final del orden de combinación de índices para evitar file_sort y afectar el rendimiento de la consulta.

• Por ejemplo, para el enunciado donde a =? Y b =? Ordenan por c, se puede establecer un índice conjunto (a, b, c).

• Si hay una búsqueda de rango en el índice, entonces el orden del índice no se puede usar, como DONDE a> 10 ORDEN POR b;, el índice (a, b) no se puede ordenar.

11. Utilice un índice corto (también llamado índice de prefijo) para optimizar el índice.

El índice de prefijo es utilizar el prefijo de la columna en lugar de toda la columna como clave de índice. Cuando la longitud del prefijo es apropiada, puede hacer la distinción del índice de prefijo cerca del índice de la columna completa, y al mismo tiempo reducir el tamaño y tamaño del archivo de índice porque la clave de índice se acorta. Para gastos generales de mantenimiento, recuento (distinto a la izquierda (nombre de la columna, longitud del índice)) / recuento (*) se puede utilizar para calcular la distinción del índice de prefijo.

El índice de prefijo tiene en cuenta el tamaño del índice y la velocidad de la consulta, pero su desventaja es que no se puede usar para operaciones ORDER BY y GROUP BY, ni para cubrir índices (Covering Index, es decir, cuando el índice mismo contiene todos los datos requeridos para la consulta, ya no se accede al archivo de datos), en muchos casos no es necesario indexar todos los campos, y la longitud del índice se puede determinar de acuerdo con la discriminación de texto real.

Por ejemplo, la siguiente declaración SQL:

SELECCIONAR  * DE empleados.empleados DONDE first_name = 'Eric'AND last_name =' Anido ';

Podemos crear un índice: (nombre, apellido (4)).

12. No se permite que la columna a indexar sea nula.

Los índices de una sola columna no almacenan valores nulos y los índices compuestos no almacenan valores totalmente nulos. Si se permite que la columna sea nula, es posible que obtenga conjuntos de resultados "inesperados". Por lo tanto, utilice la restricción no nula y la predeterminada valor.

13. Utilice asociaciones o subconsultas retrasadas para optimizar escenarios de superpágina.

MySQL no omite las filas de desplazamiento, pero toma el desplazamiento + N filas, luego devuelve las filas de desplazamiento antes de darse por vencido y devuelve N filas. Cuando el desplazamiento es particularmente grande, la eficiencia es muy baja o controla el número total de páginas devueltas o reescritura de SQL para el número de páginas que superan un determinado umbral.

El ejemplo es el siguiente, primero localice rápidamente el segmento de identificación que debe obtenerse y luego asocie:

seleccione a. *  de 表 1 a, ( seleccione id de 表 1  donde 条件 límite 100000,20) b  donde  a.id = b.id

14. Los campos con características únicas en los negocios, incluso si es una combinación de múltiples campos, deben construir un índice único.

No crea que el índice único afecta la velocidad de inserción, esta pérdida de velocidad se puede ignorar, pero es obvio mejorar la velocidad de búsqueda. Además, incluso si se realiza un control de verificación muy completo en la capa de aplicación, siempre que no haya un índice único, de acuerdo con la ley de Murphy, se deben generar datos sucios.

15. Es mejor no unir más de tres mesas.

Los tipos de datos de los campos que se deben unir deben ser coherentes. Cuando se asocian varias tablas con consultas, asegúrese de que los campos asociados deben tener índices.

16. Si sabe que solo se devuelve un resultado, el límite 1 puede mejorar la eficiencia.

Por ejemplo, la siguiente declaración SQL:

seleccione  *  fromuser donde  login_name =?

Puede optimizarse como:

seleccione  *  fromuser donde  login_name =? límite  1

Sé claramente que solo hay un resultado, pero la base de datos no lo sabe, así que lo digo claramente y dejo que detenga activamente el movimiento del cursor.

17. Optimización del rendimiento de SQL explique el tipo: al menos para alcanzar el nivel de rango, el requisito es el nivel de referencia, si puede ser consts el mejor.

• consts: hay como máximo una fila coincidente (clave principal o índice único) en una sola tabla, y los datos se pueden leer durante la fase de optimización.

• ref: Utilice un índice normal (índice normal).

• rango: realiza una búsqueda de rango en el índice.

• Cuando type = index, el archivo físico de índice se escanea completamente y la velocidad es muy lenta.

18. Se recomienda controlar el índice de tabla única dentro de 5.

19. No se permite que el número de campos de índice único exceda de 5.

Cuando hay más de 5 campos, ya no puede filtrar los datos de forma eficaz.

20. Evite los siguientes conceptos erróneos al crear un índice

• Cuantos más índices, mejor, pensando que una consulta necesita construir un índice.

• Ning Que no está invadido, ya que cree que el índice consumirá espacio y ralentizará seriamente la velocidad de las actualizaciones y las nuevas incorporaciones.

• Resista el índice único, creyendo que la unicidad de la empresa debe resolverse en la capa de aplicación a través de "comprobar antes de insertar".

• Optimice demasiado pronto, comience a optimizar sin comprender el sistema.

Sobre el uso del prefijo más a la izquierda

Hay dos explicaciones a continuación:

• El principio de coincidencia de prefijos más a la izquierda, un principio muy importante, mysql siempre coincidirá con la derecha hasta que encuentre una consulta de rango (>, <, between, like) y deje de coincidir , como a = 1 y b = 2 y c > 3 yd = 4 Si crea un índice en el orden de (a, b, c, d), d no usará el índice, si crea un índice de (a, b, d, c), puede todos lo usan, en el orden de a, b, d Se puede ajustar arbitrariamente.
• = Y puede estar desordenado, como a = 1 y b = 2 y c = 3 El índice se puede establecer en cualquier orden (a, b, c), y el optimizador de consultas de MySQL lo ayudará a optimizarlo en una forma que el índice puede reconocer