11 situaciones en las que MySQL es adecuado para crear índices

Un diseño de índice deficiente o la falta de índices afectará el rendimiento de la base de datos y la aplicación

limitar el número de índices

El número de índices no es tanto como sea posible. Se recomienda que no se utilicen más de 6 índices para una sola tabla. Razones:

  1. Cada índice ocupa espacio en disco, cuantos más índices, más espacio en disco requerido
  2. El índice afectará los nombres de instrucciones como INSERTAR, ELIMINAR, ACTUALIZAR, etc., porque cuando los datos de la tabla cambien, el índice también se ajustará y actualizará, lo que generará una carga.
  3. Cuando el optimizador selecciona la siguiente consulta optimizada, seleccionará cada índice disponible en función de la información unificada para generar el mejor plan de ejecución. Si hay muchos índices que se pueden usar para la consulta al mismo tiempo, aumentará la optimización de MySQL. El tiempo que tarda el servidor en generar un plan de ejecución reduce el rendimiento de las consultas.

Las siguientes situaciones son adecuadas para crear índices:

1.  El valor del campo tiene restricciones únicas

El índice en sí mismo puede actuar como una restricción. Por ejemplo, un índice único y un índice de clave principal pueden actuar como una restricción única. Por lo tanto, en nuestra tabla de datos, si , puede ser directamente , o . Esto permite que el índice se use para determinar más rápidamente un registro. 某个字段是唯一的创建唯一性索引主键索引

  • Los campos con características únicas en los negocios, incluso los campos compuestos, deben integrarse en un índice único. (Fuente: Alibaba)

Explicación: No piense que el índice único afecta la velocidad de inserción. Esta pérdida de velocidad puede ignorarse, pero es obvio mejorar la velocidad de búsqueda.

2. Campos  usados ​​frecuentemente como  condiciones de consulta WHERE 

Un determinado campo se usa a menudo en la condición WHERE de la instrucción SELECT, por lo que es necesario crear un índice para este campo. Especialmente en el caso de una gran cantidad de datos, la creación de un índice común puede mejorar en gran medida la eficiencia de la consulta de datos.

3.  Columnas frecuentes  GROUP BY  y  ORDER BY 

La indexación es para almacenar o recuperar datos en un orden determinado, por lo que cuando usamos GROUP BY para agrupar y consultar datos, o usamos ORDER BY para ordenar datos, lo necesitamos . Si hay varias columnas para ordenar, se puede establecer en estas columnas . 对分组或者排序的字段进行索引 组合索引

 4. Columna de condición DONDE de  ACTUALIZAR y ELIMINAR 

Después de consultar los datos de acuerdo con una determinada condición, realice una operación de ACTUALIZAR o ELIMINAR.Si se crea un índice para el campo DONDE, la eficiencia puede mejorar considerablemente. El principio se debe a que necesitamos recuperar este registro en función de la columna de condición WHERE primero y luego actualizarlo o eliminarlo. Si el campo actualizado es un campo no indexado al actualizar, la eficiencia mejorada será más obvia, porque la actualización del campo no indexado no necesita mantener el índice.

5. El campo DISTINCT  necesita crear un índice

A veces necesitamos deduplicar un campo determinado, usar DISTINCT, luego crear un índice para este campo también mejorará la eficiencia de la consulta.

Motivo: Los valores clave de los campos en el índice se ordenan en orden descendente o ascendente. En este momento, es muy rápido deduplicar los campos y se deduplican directamente en orden. Si hay valores duplicados entre datos adyacentes, se desduplicarán y, si no existen, se desduplicarán No se requiere desduplicación.

6.  Precauciones para la creación de índices cuando la operación de conexión JOIN de varias tablas  

En primer lugar 连接表的数量尽量不要超过 3 张, debido a que agregar una tabla es equivalente a agregar un bucle anidado, el orden de magnitud del crecimiento será muy rápido, lo que afectará seriamente la eficiencia de la consulta.

En segundo lugar, 对 WHERE 条件创建索引porque DÓNDE está el filtrado de las condiciones de los datos. Si la cantidad de datos es muy grande, da mucho miedo filtrar sin condiciones WHERE.

Finalmente, 对用于连接的字段创建索引y el campo está en varias tablas 类型必须一致.

razón:

  • Si los tipos de los campos utilizados para la conexión no son coherentes, MySQL convertirá implícitamente el tipo de datos (utilizará automáticamente la función) y la conversión del tipo de datos del campo hará que el índice deje de ser válido .

como:

  • tabla1.idusuario = tabla2.idusuario;
  • --table1.userId: tipo VARCHAR
  • --table2.userId; es tipo INT

Al conectarse, convertirá automáticamente el ID de usuario a INT para realizar una conexión equivalente

7.  Crea un índice con un tipo de columna pequeña

De lo que estamos hablando aquí 类型大小se refiere al tamaño del rango de datos representado por este tipo.

  • Cuanto más pequeño sea el tipo de datos, más rápida será la operación de comparación en el momento de la consulta
  • Cuanto más pequeño es el tipo de datos, menos espacio de almacenamiento ocupa el índice y se puede almacenar en una página de datos 放下更多的记录, lo que reduce I/Ola pérdida de rendimiento causada por el disco, lo que significa que se pueden almacenar más páginas de datos en la memoria caché, lo que acelera la lectura. Eficiencia de escritura.

Esta sugerencia es para la tabla 主键来说更加适用, porque no solo el valor de la clave principal se almacenará en el índice agrupado, sino que también el valor de la clave principal de un registro se almacenará en los nodos de todos los demás índices secundarios. tipo de datos, significa Esto conduce a un mayor ahorro de espacio de almacenamiento y una E/S más eficiente.

8.  Crea un índice con un prefijo de cadena

Supongamos que nuestra cadena es muy larga, entonces almacenar una cadena requiere mucho espacio de almacenamiento. Cuando necesitamos crear un índice para esta columna de cadena, significa que existen los dos problemas siguientes en el árbol B+ correspondiente:

  • Los registros en el índice del árbol B+ necesitan almacenar la cadena completa de la columna, lo que consume más tiempo y cuanto más larga sea la cadena, mayor será el espacio de almacenamiento ocupado en el índice.
  • Si las cadenas almacenadas en el índice en el índice del árbol B+ son muy largas, llevará más tiempo comparar las cadenas .

Podemos construir un índice interceptando la primera parte del campo, que se llama índice de prefijo . De esta manera, aunque la ubicación del registro no se puede ubicar con precisión al buscar el registro, se puede ubicar la ubicación del prefijo correspondiente y luego se puede consultar el valor de la cadena completa en la tabla de acuerdo con el valor de la clave principal del registro con el mismo prefijo. Ahorra espacio, reduce el tiempo de comparación de cadenas y, en general, resuelve el problema de clasificación.

Por ejemplo: cree una tabla de productos, porque el campo de dirección es largo, cree un índice de prefijo en el campo de dirección

CREATE TABLE SHOP(address varchar(120) not null);

--给字段address建立前缀索引
alter table shop index(address(12))

El problema existente es: ¿Cuánto se necesita interceptar la cadena para que sea apropiada? Si hay demasiada interceptación, no se logrará el propósito de ahorrar espacio de almacenamiento de índice; si hay menos interceptación, habrá demasiada repetición y el grado de hash (selectividad) del campo disminuirá. ¿Cómo calcular la selectividad de diferentes longitudes?

Primero observe la selectividad del campo en todos los datos:

select  count(distinct address)/count(*)  from shop;

Calcular por diferentes longitudes, en comparación con la selectividad de la tabla completa: 

oficial:

  • La izquierda aquí es una función en la cadena, que indica cuántos caracteres se deben tomar delante del campo de la cadena.
count(distinct left(列名, 索引长度))/count(*)

Por ejemplo:

select 
    count(distinct left(address,10)) / count(*)  as sub10    --截取前10个字符的选择度

    ,count(distinct left(address,15)) / count(*)  as sub15    --截取前15个字符的选择度

    ,count(distinct left(address,20)) / count(*)  as sub20    --截取前20个字符的选择度
from shop;
  •  Cuanto más se acerque el resultado del cálculo a 1, mejor. Durante la prueba, si se descubre que después de que todas las configuraciones se establecen en 30, los resultados del cálculo posterior cambian muy poco, entonces puede establecer 30 como la longitud del índice de prefijo óptimo

El efecto del prefijo de columna de índice en la clasificación:

  • El índice de prefijo no contiene información de cadena completa, por lo que cuando se ordena el índice, no se puede garantizar que el orden de los registros sea correcto. Por lo tanto,  el método de índice de prefijo no admite el uso de clasificación de índice y solo se puede clasificar el índice de archivo. usado

Expansión: Alibaba "Manual de desarrollo de Java"

[ 强制] Al crear un índice en un campo varchar, se debe especificar la longitud del índice. No es necesario crear un índice para todo el campo, y la longitud del índice se determina de acuerdo con la discriminación de texto real.

Explicación: La longitud y la discriminación del índice son un par de contradicciones. Generalmente, para datos de tipo cadena, un índice con una longitud de 20 tendrá la misma discriminación 高达 90% 以上.

9.  Las columnas con alta discriminación (alta capacidad de hash) son adecuadas como índices

列的基数Se refiere a la cantidad de datos únicos en una columna , por ejemplo, si una columna contiene valores 2,5,8,2,5,8,2,5,8, aunque hay 9registros, la cardinalidad de la columna es 3. Es decir, en el caso de un número determinado de filas de registros, cuanto mayor sea la cardinalidad de la columna, más dispersos serán los valores en la columna; cuanto menor sea la cardinalidad de la columna, más concentrados serán los valores en la columna El índice de cardinalidad de esta columna es muy importante, lo que afecta directamente si podemos usar el índice de manera efectiva. Lo mejor es crear un índice para una columna con una cardinalidad grande y el efecto de crear un índice para una columna con una cardinalidad pequeña puede no ser bueno.

Puedes utilizar una fórmula select count(distinct a)/count(*) from t1para calcular el grado de discriminación, cuanto más cerca de 1 mejor, generalmente es 33%un índice más eficiente si supera 1.

Expansión: El índice conjunto pone las columnas con alta discriminación (alta capacidad de hash) al frente.

10.  Coloque las columnas utilizadas con mayor frecuencia en el lado izquierdo del índice conjunto

  • Asegúrese de que la condición pueda usar el índice conjunto
  • En el siguiente índice conjunto, order by se ejecuta antes que group by, por lo que las columnas después de order by deben estar delante del índice conjunto, y las columnas después del grupo b están detrás del índice conjunto.
SELECT * FROM STUDENT
ORDER BY SCORE
GROUP BY NAME;
--需要创建SCORE和NAME的联合索引:idx_score_name(score esc,name esc)
--esc默认不需要添加,当order by score desc时,需要改为idx_score_name(score desc,name esc)

11.  En el caso de que sea necesario indexar varios campos, el índice conjunto es mejor que el índice de valor único

Supongo que te gusta

Origin blog.csdn.net/weixin_42675423/article/details/131715503
Recomendado
Clasificación