Optimización del índice MySQL de un vistazo (caso real)

antecedentes

(Base de datos utilizada: MYSQL versión 5.7, motor InnoDB)
Desde que se agregó Skywalking al servicio, se han expuesto la mayoría de las interfaces lentas. Entonces está la optimización de esta interfaz lenta. El proceso de optimización aproximado.

Antes de la optimización:
Optimizado:

Pasos de optimización

1. Investigación

A través de skywalking, puede ver claramente en qué paso la interfaz lenta es más lenta. A través de la situación de la llamada, puede ver claramente la situación de la llamada de enlace como se muestra a continuación:

Si su servicio no está conectado al servicio de monitoreo en esta situación, entonces podemos usar Arthas de código abierto de Alibaba para rastrear el enlace (use trace para ver el método que consume mucho tiempo de cada paso) documento oficial de arthas

2. Registre la situación actual

Después de la investigación, podemos ubicar con precisión el SQL es muy lento. En este momento, tenemos que analizar este SQL cuidadosamente, primero sacar el SQL comercial (obtenido a través del registro de la consola) y ver el plan de ejecución de SQL a través de explicar. Muy importante. Verifique si hay un índice móvil, verifique el número de filas de escaneo previo, la estrategia de ejecución, etc. Las palabras aquí se basan principalmente en la información que nos proporciona cada campo de la explicación. (Running es la biblioteca de producción). Registre la información principal obtenida.

Índice utilizado	Número de líneas de exploración previa	Ya sea para volver a la mesa	Ya sea para ordenar	Tiempo de ejecución	En conclusión

3. Determinar el plan de optimización específico según la situación y analizar las razones.

1. Índice incorrecto

1. - 这种情况我们呢可以查看他的索引基数通过 show index from table_name.大概看一下cardinality基数字段，大概评估一下。然后使用命令 analyze table tb_name重新计算一下。
    - 因为对与mysql选择索引其中索引基数是重要条件之一
    - 索引基数是通过抽样计算计算出来的，所以不一定是准确的，所以通过analyze table进行重新采样计算后就可以了。
2. - 如果说通过索引基数还没有OK的话，那就有可能是在这条语句中与可能有排序或者有创建临时表的情况，使用这个你认为扫描行数少的有可能产生。所以你可以考虑优化索引了，创建一个符合索引且不需要回表的

2. Discriminación de bajo índice

Lo que debe tenerse en cuenta aquí es usar algunos valores de estado lo menos posible para crear índices. ¿por qué? Después de construir un árbol B +, la mayoría de sus valores son los mismos, y es probable que la complejidad temporal de la búsqueda sea aproximadamente la misma que la de una lista vinculada ordinaria. Aquí realmente podemos matarlo de manera decisiva.
La otra es que la primera mitad es básicamente la misma, y la última parte tiene algunas diferencias. En este caso, podemos usar el almacenamiento flashback y luego usarlo para crear un índice, y solo usar la parte con un alto grado de distinción para el almacenamiento. En otras palabras, almacene un campo más como valor hash y use el valor hash como índice. Utilice el hash calculado directamente para hacer coincidir al buscar

3. Utilice el índice para volver a la tabla, hay clasificación

Regresar a la tabla significa que los datos que encontramos a través de un índice no pueden recorrer lentamente los campos que necesitamos, y él necesita escanear el ID recopilado a través del índice de clave principal para obtener la información del campo correspondiente. Entonces nuestra solución es utilizar un índice de cobertura. Cree un índice que cumpla con los campos obligatorios. Lo que hay que señalar aquí es que ya ha sido evaluado. No se puede crear un índice conjunto con una sola consulta. La otra es cumplir con el principio de coincidencia más a la izquierda y el grado de discriminación debe ser grande.
Hay ordenación, es decir, cuando hay ordenación de archivos al explicar, esta operación realizará operaciones de IO y ordenación. Entonces creamos un índice conjunto con este campo. Por ejemplo, consultamos el índice conjunto del pedido correspondiente al id según el ID del usuario y lo ordenamos por create_time. De hecho, existe otra situación que es que si el pedido del usuario tiene varios millones de pedidos, el rendimiento de la consulta disminuirá de una vez, entonces podemos usar Los requisitos comerciales se optimizan, es decir, se limita un intervalo de tiempo en la declaración where.

（id，create_time）

4. Mi plan final para SQL es cambiar dos y agregar uno

Cambie el índice con baja discriminación y no siga el principio de coincidencia más a la izquierda
Cree un índice conjunto para eliminar la clasificación de archivos
Optimización de la lógica empresarial, optimización simple de SQL complejo, eliminación de la lógica anidada
Combine la lógica empresarial con el intervalo de tiempo (un mes antes de la hora actual).

3. Verificación estricta y eficaz

Éste es el paso más importante

Mi plan de verificación:

Gracias a mi propio conocimiento del negocio, calculo la declaración de índice modificada que se utilizará y la pruebo. Aquí puede compararla con la biblioteca de producción.
Se ha registrado el uso del índice original y luego se ejecuta el SQL original en la base de datos del entorno SIT y (nuestra biblioteca SIT ha sincronizado datos de PROD, pero todavía faltan algunos datos)
Cuando ejecute SQL, intente elegir las condiciones del filtro en la medida de lo posible: use el índice, y los datos no se filtrarán, para evitar la situación accidental de que los datos se clasifiquen al frente y se golpeen muy temprano.
Luego, los estudiantes de la prueba realizarán una prueba de presión con nuestra interfaz optimizada.
Es una prueba de regresión completa. Haga clic en cada página de consulta
Afortunadamente, el rendimiento se ha mejorado en 1000 de decenas de segundos a menos de 1 ms y no tiene ningún efecto en otras interfaces comerciales.

4. El índice está en línea

Cambiar el índice no es más que eliminar el índice y crear el índice. Aquí debe prestar atención a la tabla de bloqueo que puede producirse durante el proceso de cambio. Aquí podemos echar un vistazo a la sintaxis de Online DDL (https://dev.mysql.com/doc/refman/5.7/en/ innodb-online-ddl-operations.html)
El negocio de la empresa lo permite, pero detuve el servicio en medio de la noche. Pero se ejecutó durante 1 hora (9 millones de datos)

Alucinación

En el trabajo real, muchos estudiantes piensan que agregar un índice afectará la eficiencia de la actualización. Pero este impacto es muy pequeño por el impacto de las consultas lentas.

para resumir

Un proceso que optimicé yo mismo
El uso de explicar (https://segmentfault.com/a/1190000008131735)
Varios casos de problemas de índice
Las pruebas estrictas son muy importantes (mi prueba personalmente cree que es promedio)

datos

Índice optimizado de Meituan: https://tech.meituan.com/2014/06/30/mysql-index.html
Uso de expalin: https://dev.mysql.com/doc/refman/5.7/en/using-explain.html
Sintaxis DDL en línea: https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html
Arthas documento oficial: https://alibaba.github.io/arthas/trace.html)