Optimización de la base de datos MySQL dos o tres cosas

VOL 172

2020-10

Hoy son 56 días antes de 2021

Este es el tweet número 172 de ITester Software Testing Stack

Haga clic en la palabra azul superior " ITester software testing Flowering " Me preocupa, una, tres, cinco de la mañana todas las semanas 08: 3 0 empuje puntual cada mes de vez en cuando se presentan libros técnicos .

La cuenta oficial de WeChat entre bastidores responde a " recursos " y " kit de prueba " para recibir recursos de prueba, y responde al " grupo de WeChat " para unirse al grupo para luchar contra monstruos.

Este artículo tiene 4.317 palabras, aproximadamente 11 minutos de lectura

Por lo general, cuando se desarrollan nuevos proyectos, a veces debido al apretado calendario, a menudo apuntan a realizar la función y prestan poca atención a los problemas de eficiencia, especialmente en las declaraciones SQL.

¿Cuáles son los métodos comunes de optimización de bases de datos? En pocas palabras, es agregar índices, reconstruir la estructura, matar el proceso, matar al DBA ... Si estás en una empresa sin DBA, es un buen momento para conectarte, y luego el crematorio, el humilde prueba toma accidentalmente el lado equivocado.

¿Cómo aliviar las preocupaciones? Solo estudia y practica. Los probadores también se ocuparán de los datos y hoy resumirán el conocimiento de optimización de la base de datos. Principalmente presenta las formas en que se puede optimizar la base de datos y se puede mejorar la eficiencia de ejecución de la base de datos.

Uno

Problemas existentes del sistema

Antecedentes del problema

"El sistema lento no es un problema, siempre y cuando no se bloquee", esta puede ser la idea de la mayoría de las escuelas de tecnología del cáncer perezosas. Sin embargo, si el sistema a menudo arroja algunas fallas (excepto por problemas de hardware, pero si el disco se rompe a menudo, también puede estar relacionado con el rendimiento). Muchas veces se debe a que: no se utilizan variables de enlace, se configuran incorrectamente algunos parámetros del optimizador, concurrencia excesiva, falta de índices (lo más común), estadísticas inexactas, escritura de SQL deficiente, el sistema RAC está diseñado según un solo nodo, etc. de problemas de rendimiento que resultan en una presión excesiva del sistema. Sin embargo, los cánceres perezosos en etapa tardía a menudo prefieren combatir el fuego cuando algo sale mal, en lugar de dedicar tiempo a optimizar la base de datos. Imagínese si el sistema está completamente optimizado y la carga es pequeña, ¿ocurrirán varios problemas a menudo? Se puede optimizar el 100% de la base de datos, la CPU se reduce, la contención de recursos es pequeña, el sistema será más estable, la presión de E / S se reduce, la velocidad de ejecución de SQL se acelera y la vida útil del disco será más larga.

análisis del problema

Problema de diseño : demasiados índices de una sola columna, demasiados índices totales, fácil fusión de índices, el optimizador no puede seleccionar el mejor índice, indirectamente conduce al uso de todos force indexy el optimizador no puede seleccionar automáticamente el plan de ejecución de manera inteligente.

Problemas de uso : consulta universal, múltiples interfaces, consulta de todas las columnas, índice de abuso de fuerza, volumen de datos excesivo en una sola tabla y escritura SQL irregular.

dos

Exploración de consultas lentas en la base de datos

Fenómeno problema

¿Cuáles son las razones de la lenta ejecución de sentencias SQL? Esta pregunta puede implicar una gran cantidad de conocimientos básicos de MySQL, al igual que la pregunta "qué sucedió después de ingresar la URL y el retorno de carro" al examinar redes de computadoras.

Las sentencias SQL se ejecutan muy lentamente, pero ¿cada vez se ejecutan muy lentamente? ¿O es normal en la mayoría de los casos y muy lento en ocasiones? Calificamos las siguientes 2situaciones para discutir:

Con la misma cantidad de datos, esta instrucción SQL se ha ejecutado muy lentamente.
La mayoría de las situaciones son normales, pero ocasionalmente habrá situaciones muy lentas.

Ante estas dos situaciones, analicemos las posibles causas.

Análisis de causa

En general, la ejecución lenta de sentencias SQL puede deberse a las siguientes razones:

Demasiadas líneas de exploración;
Se devolvieron demasiadas filas;
Operaciones adicionales (clasificación, agrupación, cálculo);

Según el grado de lentitud de ejecución de SQL, analizaremos en detalle dos situaciones:

Esta instrucción SQL se ha ejecutado muy lentamente por las siguientes razones:

No se utilizan índices: los índices no se pueden utilizar debido a operaciones y operaciones de funciones en campos.
La base de datos seleccionó el índice incorrecto.

Es normal en la mayoría de los casos, y ocasionalmente lento, por las siguientes razones:

La base de datos está descargando páginas sucias. Por ejemplo, el registro de rehacer está lleno y debe sincronizarse con el disco.
Durante la ejecución, se encuentran bloqueos, como bloqueos de tabla y bloqueos de fila.

identificar el problema

Podemos localizar el SQL problemático activando el registro de consultas lento y encontrando la fuente del problema.

(1) Compruebe si MySQL ha habilitado el registro de consultas lento:

show variables like 'slow_query_log';

(2) Establezca registros sin índice en el registro de consultas lento:

set global log_queries_not_using_indexes=on;

(3) Compruebe cuánto tiempo se registra el SQL en el registro de consultas lentas:

show variables like 'long_query_time';

(4) Active el registro de consultas lentas:

set global slow_query_log=on;

(5) Configure el tiempo de espera:

set global long_query_time=5;
--超过5s的语句才记录日志

(6) Ver la ubicación del registro de consultas lentas:

show variables like 'slow%';

Tres

Principios de optimización de bases de datos

Optimización de la estructura de la mesa

1. Se debe establecer la clave principal para la tabla recién creada. Se recomienda el ID de autoincremento y se recomienda el tipo bigint sin firmar.

2. Todos los campos deben tener comentarios y las tablas deben tener comentarios.

3. Todos los campos deben configurarse como no nulos en la medida de lo posible. Si hay un valor predeterminado, indíquelo, si no, no lo escriba. Está prohibido usar el NULL predeterminado. Se recomienda que el tipo de carácter sea el valor por defecto.

4. La tabla debe incluir borrado lógico, creador, hora de creación, hora de modificación, comentarios;

5. El orden es fijo y coherente, y se ha mantenido al final de la lista.

Por ejemplo, copie de la siguiente manera:

is_delete TINYINT(1) UNSIGNED NOT NULL DEFAULT 0 COMMENT '是否删除，默认0：有效，1：失效。',
createdby MEDIUMINT(8) UNSIGNED NOT NULL DEFAULT 0 COMMENT '创建人',
created INT(10) UNSIGNED NOT NULL DEFAULT 0 COMMENT '创建时间',
changed_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
remarks VARCHAR(100) NOT NULL DEFAULT '' COMMENT '备注，保留字段'

Optimización de índices

1. El principio de coincidencia de prefijos más a la izquierda, el orden en el que las condiciones deben ser lo más coherentes posible con el orden de las columnas de índice.

2. Intente elegir una columna con un alto grado de discriminación como índice.

3. Al crear un nuevo índice, las consultas de rango más utilizadas se colocan mejor al final del índice.

4. Ver la dispersión del índice, mostrar el índice de his.tb_api_log.

5. Los índices no deben usarse en tipos de caracteres y campos que no se actualizan con frecuencia.

6. Los campos con nombre de índice con idx_field1_field2_fieldn se pueden abreviar y el orden no se puede alterar.

Optimización de la configuración de la base de datos

`连接数`(conexión) configuración: cuando se descubre que MySQL tiene la capacidad de manejar más simultaneidad, se recomienda aumentar el valor de max_connections, lo que traerá una carga mayor (CPU / IO / memoria) al servidor en consecuencia.

查询缓存(query_cache) configuración: la caché de consultas de MySQL se utiliza para almacenar en caché los resultados de las consultas seleccionadas, y cuando se recibe la misma solicitud de consulta la próxima vez, el procesamiento real de la consulta ya no se ejecuta y los resultados se devuelven directamente. Tal caché de consultas puede mejorar la velocidad de la consulta y hacer que el rendimiento de las consultas esté optimizado.

临时表缓存(tmp_table_size) configuración: Cuando MySQL realiza consultas complejas u operaciones avanzadas de GROUP BY, el sistema genera algunas tablas temporales para optimizar la consulta. En circunstancias normales, MySQL primero creará una tabla temporal de memoria, pero cuando la tabla temporal de memoria exceda el valor especificado en la configuración, MySQL exportará la tabla temporal de memoria a la tabla temporal del disco.

索引缓冲区Configuración (Key_buffer_size): Es un parámetro que tiene el mayor impacto en el rendimiento de las tablas MyISAM. Key_buffer_size especifica el tamaño del búfer de índice, que determina la velocidad de procesamiento del índice, especialmente la velocidad de lectura del índice. Al verificar los valores de estado Key_read_requests y Key_reads, puede saber si la configuración key_buffer_size es razonable.

Optimización de recursos de hardware

La optimización del nivel de hardware es el último recurso, que principalmente debe considerar varios aspectos como CPU, almacenamiento y red.

CPU: Cuanto más CPU no es mejor, aumentar el número de CPU no mejorará el rendimiento.

存储: Disco mecánico o SSD (SSD es más rápido, por supuesto), un solo disco grande o varios discos pequeños se utilizan en combinación (un solo disco de 1T no debe ser tan rápido como una combinación de dos discos de 500G, porque la velocidad de rotación del disco es fija , dos discos Equivalente a lectura en paralelo).

网络: Generalmente no es un problema, pero en un entorno de clúster distribuido, el entorno de red entre varios nodos de la base de datos a menudo se denomina cuello de botella del sistema. Además, si el servidor y la base de datos están ubicados en diferentes ciudades, el tiempo para una transmisión SQL simple puede ser de decenas de milisegundos.

cuatro

Resumen de optimización de la base de datos

De hecho, es necesario estimar el posible volumen de negocio y el volumen de datos en la etapa de análisis de demanda, de modo que el diseño pueda ser focalizado al construir la tabla. De lo contrario, sería un gamberro hablar de optimización más allá de los requisitos. Así como no existe una medicina mágica para todas las enfermedades en este mundo, no habrá una tecnología perfecta para resolver todos los problemas. Por lo tanto, el diseño de la base de datos debe estar relacionado con los requisitos, porque la estructura de la tabla también debe cumplir con los requisitos, y el diseño de una base de datos también está estrechamente relacionado con los requisitos. Un requisito reflejará si una tabla se centra en la lectura o la escritura. El diseño de datos debe seguir los siguientes principios tanto como sea posible:

La instrucción SQL es lo más simple posible y la gran SQL se divide en pequeñas declaraciones SQL;
La transacción debe ser simple, la duración de toda la transacción no debe ser demasiado larga y el orden de las diferentes transacciones para actualizar la tabla debe ser coherente;
Tenga en cuenta que la actualización que no está de acuerdo con el índice provoca una gran área de bloqueo (primero debe verificar y luego actualizar con la clave principal);
Evite el uso de disparadores, funciones, procedimientos almacenados, eventos;
Reducir el acoplamiento empresarial (evitar la consulta universal, que es más grave);
Utilice la consulta de rango con precaución;
Evite las operaciones matemáticas en la base de datos (MySQL no es bueno para operaciones matemáticas y juicios lógicos);
No use select *, simplemente seleccione estos campos para realizar consultas;
Está prohibido comparar campos de diferentes tipos para evitar la conversión implícita;
Cuando el parámetro like comienza con un comodín;
como Intente utilizar la indexación de texto completo (la tabla de particiones no admite la indexación de texto completo);
Se recomienda controlar el número de dígitos en in dentro de 1000;
Preste atención a la eficacia de la paginación límite. Cuanto mayor sea el límite, menor será la eficiencia, que se puede cambiar a asociación retardada. Este es el método de optimización más eficaz y comúnmente utilizado en consultas de tabla única de gran volumen de datos;
Evite unir mesas grandes;
Las actualizaciones de big data deben actualizarse en lotes, no actualice demasiados datos a la vez (de lo contrario, puede causar bloqueo y contención de bloqueo);
Reducir el número de interacciones con la base de datos (grupo de conexiones);
Preste atención al uso de herramientas de análisis de desempeño;
Tenga en cuenta que el programa detecta la excepción e imprime el registro;
Formatee la instrucción SQL;
Utilice explicar más para ver el plan de ejecución;