Cinco dimensiones de la optimización del rendimiento de MySQL

Cinco dimensiones de la optimización del rendimiento de MySQL

1. Optimización de la configuración de la conexión de la base de datos

1. Lo que el servidor debe hacer es aceptar tantas conexiones de clientes como sea posible. Quizás haya encontrado el error 1040: ¿Demasiadas conexiones? Es solo que la cantidad de conexiones en el lado del servidor no es suficiente.
2. Lo que puede hacer el cliente es minimizar el número de veces que establece conexiones con el servidor. Usar las conexiones ya establecidas si se pueden usar. No crear una nueva conexión cada vez que ejecute una sentencia SQL. Los recursos de ambos El servidor y el cliente se verán abrumados.

1. Configuración optimizada del número máximo de conexiones al servidor.

Lo que el servidor debe hacer es aceptar tantas conexiones de clientes como sea posible. Quizás haya encontrado el error 1040: ¿Demasiadas conexiones? Es solo que la cantidad de conexiones en el lado del servidor no es suficiente.
Lo que el cliente puede hacer es minimizar el número de veces que establece una conexión con el servidor. Usar las conexiones existentes si se pueden usar. No crear una nueva conexión cada vez que se ejecuta una declaración SQL. Los recursos tanto del servidor y el cliente quedará abrumado.

La solución es utilizar un grupo de conexiones para reutilizar las conexiones.
El problema de las conexiones insuficientes se puede resolver desde dos aspectos:
(1) Método 1: aumentar el número de conexiones disponibles y modificar la variable de entorno max_connections. De forma predeterminada, el número máximo de conexiones en el servidor es 151
mysql> mostrar variables como ' max_connections';
± ----------------±------+
| Nombre_variable | Valor |
±---------------- ±--- ---+
| max_connections | 151 |
±----------------±------+
1 fila en conjunto (0,01 seg)
Insertar descripción de la imagen aquí

establecer GLOBAL max_connections=1000; #Modificar el número máximo de conexiones a 1000
Insertar descripción de la imagen aquí

(2) Método 2
/etc/my.cnf #Agregue la configuración
max_connections=1500 al archivo de configuración de la base de datos #Modifique el número máximo de conexiones a 1500
y luego reinicie la base de datos.
Insertar descripción de la imagen aquí
Insertar descripción de la imagen aquí

2. Liberar conexiones inactivas

Libere conexiones inactivas de manera oportuna. El tiempo de espera predeterminado del cliente del sistema es 28800 segundos (8 horas). Podemos ajustar este valor más pequeño
mysql> show variables como 'wait_timeout';
±---------- --- -±------+
| Nombre_variable | Valor |
±--------------±------+
| tiempo de espera_espera | 28800 |
±---- --- -------±------+
1 fila en conjunto (0,01 seg)
Insertar descripción de la imagen aquí

Modifique el archivo de configuración
/etc/my.cnf
Interactive_timeout=18800
wait_timeout=18800
Insertar descripción de la imagen aquí

Reiniciar base de datos
Insertar descripción de la imagen aquí

2. Optimización de la arquitectura

1. Usar caché

(1) Si los datos no son particularmente efectivos (no cambian en cada momento, como los informes diarios), podemos colocar este tipo de datos en el sistema de caché y, durante el período de validez de la caché de los datos, recuperarlos directamente de sistema de caché Obtenga datos de la base de datos, lo que puede reducir la presión sobre la base de datos y mejorar la eficiencia de las consultas.
Insertar descripción de la imagen aquí

2. Separación de lectura y escritura

(1) Puede utilizar varios servidores de bases de datos al mismo tiempo. Configure uno de ellos como líder del equipo, llamado nodo maestro, y los otros nodos como miembros del equipo, llamados esclavos. Los usuarios escriben datos solo en el nodo maestro y las solicitudes de lectura se distribuyen a varios nodos esclavos. Esta solución se llama separación de lectura y escritura.
Insertar descripción de la imagen aquí

(2) El uso de un clúster inevitablemente enfrentará un problema: la replicación maestro-esclavo para mantener la coherencia de los datos entre múltiples nodos.
Binlog es el componente central que implementa la función de replicación maestro-esclavo de MySQL.
①. El subproceso IO del lado esclavo envía una solicitud al subproceso binlog (registro binario) del lado maestro.
②. El subproceso de volcado binlog del lado maestro obtiene la información del registro binario (nombre de archivo e información de ubicación) y la envía al esclavo. -Subproceso IO del lado.
③. El contenido obtenido por el subproceso IO del lado esclavo. Escriba en el registro de retransmisión del lado esclavo (registro de retransmisión) a su vez y registre el nombre del archivo bin-log y la ubicación del lado maestro en http:/ /master.info ④. Cuando el
hilo SQL en el lado esclavo detecta que el contenido en el registro de retransmisión está actualizado, analizará el contenido actualizado en el registro de retransmisión y realizará estas operaciones para lograr coherencia con los datos maestros.

Insertar descripción de la imagen aquí

3. Subbiblioteca y subtabla

Resumen de la fragmentación de bases de datos y tablas: Resumen: la fragmentación horizontal tiene como objetivo principal resolver los cuellos de botella de almacenamiento, y la fragmentación vertical es principalmente para reducir la presión de concurrencia.

(1) Fragmentación vertical:
el significado de nodos en bases de datos de fragmentación y tablas de fragmentación es relativamente amplio. Si la base de datos se usa como nodo, es una base de datos de fragmentación; si se usa una sola tabla como nodo, es una tabla de fragmentación. .
La subdivisión de subbiblioteca y tabla se divide en subbase de datos vertical, subtabla vertical, subbase de datos horizontal y subtabla horizontal.
Insertar descripción de la imagen aquí

Sobre la base de una única base de datos, hacemos varios cortes verticales y la dividimos en diferentes bases de datos según la lógica empresarial, esta es la subbase de datos vertical.
Insertar descripción de la imagen aquí

(2) División vertical de la tabla
La división vertical de la tabla consiste en cortar uno (o varios cortes) verticalmente en una sola tabla para dividir las múltiples palabras de una tabla en varias tablas pequeñas. Esta operación debe realizarse de acuerdo con el negocio específico. Por lo general, los campos de uso frecuente (campos activos) se dividen en una tabla, y los campos que no se usan con frecuencia o no se usan inmediatamente (campos fríos) se dividen en una tabla para mejorar la velocidad de la consulta.
Insertar descripción de la imagen aquí

(3) División horizontal de la tabla:
guarde los datos de una sola tabla en varias tablas de datos de acuerdo con ciertas reglas (llamadas reglas de fragmentación en la jerga) y aplique un cuchillo (o varios cuchillos) a la tabla de datos horizontalmente, que es una partición de tabla horizontal. .
Insertar descripción de la imagen aquí
Insertar descripción de la imagen aquí

(4) Subbase de datos horizontal
La subbase de datos horizontal consiste en cortar una única base de datos horizontalmente, lo que a menudo va acompañado de una división horizontal de la tabla.
Insertar descripción de la imagen aquí
Insertar descripción de la imagen aquí

4. Cola de mensajes

Normalmente, las solicitudes de los usuarios accederán directamente a la base de datos. Si el número de usuarios en línea al mismo tiempo es muy grande, es muy probable que abrume la base de datos (consulte el estado de Weibo cuando las celebridades hacen trampa o anuncian sus relaciones).
En este caso, la presión sobre la base de datos se puede reducir mediante el uso de la cola de mensajes. No importa cuántas solicitudes de usuario haya al mismo tiempo, primero se almacenan en la cola de mensajes y luego el sistema consume las solicitudes del mensaje. cola de manera ordenada.
Insertar descripción de la imagen aquí

3. Análisis y optimización de SQL.

1. Consulta lenta

Las consultas lentas son consultas que se ejecutan muy lentamente. Solo sabiendo qué consultas lentas hay en MySQL podemos realizar una optimización específica.
Debido a que activar el registro de consultas lentas tiene un costo de rendimiento, MySQL desactiva la función de registro de consultas lentas de forma predeterminada. Utilice el siguiente comando para ver el estado actual de las consultas lentas.
mostrar variables como 'slow_query%';
mysql> mostrar variables como 'slow_query%';
±--------------------±---------- -------------------------------+
| Nombre_variable | Valor |
±------------ ---- ----±----------------------------------------+
| slow_query_log | APAGADO |
| slow_query_log_file | /var/lib/mysql/9e74f9251f6c-slow.log |
±--------------------±------- ------- -----------------------+
2 filas en el conjunto (0,00 segundos)
slow_query_log indica si el registro de consultas lentas está actualmente habilitado, y slow_query_log_file indica la ubicación de almacenamiento del registro de consultas lentas.
Además de las dos variables anteriores, también debemos determinar cuál es el indicador "lento", es decir, cuánto tiempo lleva ejecutar una consulta para que se considere una consulta lenta. El valor predeterminado es 10S. Si se cambia a 0 , se registrarán todas las variables SQL que muestren como '%long_query%
';
mysql> muestra variables como '%long_query%';
±----------------±----------+
| nombre_variable | Valor |
±----------------±----------+
| tiempo_de_consulta_largo | 10.000000 |
±----------------±----------+
1 fila en conjunto (0,00 seg)

2. Abra el registro de consultas lentas.

(1) Método 1: modifique el archivo de configuración my.cnf.
Esta modificación seguirá siendo efectiva después de que se reinicie el sistema.

#Si se debe habilitar el registro de consultas lentas
slow_query_log=ON
long_query_time=2
slow_query_log_file=/var/lib/mysql/slow.log

(2) Método 2: Modificar parámetros dinámicamente (no válido después de reiniciar)
mysql> set @@global.slow_query_log=1;
Consulta correcta, 0 filas afectadas (0,06 segundos)
mysql> set @@global.long_query_time=2;
Consulta correcta, 0 filas afectadas (0,00 seg)

3. Análisis de registro de consultas lento

MySQL no solo guarda archivos de registro lentos para nosotros, sino que también nos proporciona la herramienta de consulta de registros lentos mysqldumpslow. Para demostrar esta herramienta, primero construimos una consulta lenta: mysql> SELECT sleep(5); Ver el número de consultas lentas
registros de registro
:
MOSTRAR ESTADO GLOBAL COMO '%Slow_queries%';
Luego consultamos la consulta lenta que lleva más tiempo:

mysqldumpslow -st -t 1 -g 'select' /var/lib/mysql/9e74f9251f6c-slow.log
Leyendo el registro de consultas lentas de mysql desde /var/lib/mysql/9e74f9251f6c-slow.log
Conteo: 1 Tiempo=10.00s (10s ) Lock=0.00s (0s) Rows=1.0 (1), root[root]@localhost
SELECT sleep(N)
Entre ellos
, Count: indica el número de veces que se ejecuta este SQL.
Time: indica el tiempo de ejecución. El acumulado el tiempo entre paréntesis es
Locks: Indica el tiempo de bloqueo, y lo que está entre paréntesis es el tiempo acumulado
Filas: indica el número de registros devueltos, y lo que está entre paréntesis es el número acumulado.

cat /var/lib/mysql/data/slow.log
MOSTRAR perfiles Ver el consumo de tiempo de SQL
Consulta SQL El consumo de tiempo de todo el ciclo de vida
se puede obtener a través de Query_ID La vida completa de la estructura de cuatro capas desde la conexión - servicio - motor - tiempo de ciclo de almacenamiento
MOSTRAR perfil CPU, BLOQUEAR IO PARA CONSULTA 4;
Tipo de parámetros disponibles:
TODOS # Mostrar toda la información general
BLOQUE IO # Mostrar la sobrecarga relacionada con el bloque IO
INTERRUPTORES DE CONTEXTO #
CPU sobrecarga relacionada con el cambio de contexto # Mostrar información sobrecarga relacionada con la CPU
IPC # Mostrar enviar y recibir información general relacionada
MEMORIA # Mostrar información general relacionada con la memoria
PAGE FAULTS # Mostrar información general relacionada con fallas de página
SOURCE # Mostrar información general relacionada con Source_function, Source_file, Source_line
SWAPS # Mostrar información general relacionada con el número de intercambios

4. Ver hilos en ejecución

Podemos ejecutar mostrar lista de procesos completa para ver todos los subprocesos que se ejecutan en MySQL, ver su estado y tiempo de ejecución, encontrar sitios con tiempos de ejecución prolongados y eliminarlos directamente.
Entre ellos,
Id: el identificador único del hilo. Puede usar el Id. para eliminar el hilo especificado.
Usuario: el usuario que inició este hilo. Las cuentas normales solo pueden ver sus propios hilos.
Host: qué IP y puerto iniciaron la conexión. .db
: la base de datos operada por el hilo
.Comando: el comando del hilo
Tiempo: duración de la operación, en segundos
Estado: el estado del hilo
Información: los primeros 100 caracteres de la declaración SQL

5. Verifique el estado de ejecución del servidor.

Usar directamente el comando show status para obtener más de 300 registros nos deslumbrará, por lo que esperamos poder "ver" cierta información de estado a pedido. En este momento, podemos agregar la cláusula similar correspondiente después de la declaración de estado del espectáculo. Por ejemplo, si queremos ver el tiempo de ejecución actual de MySQL después de iniciarlo, podemos ejecutar la siguiente instrucción:
Utilice el comando MOSTRAR ESTADO para ver la información de estado del servidor.
Los comandos específicos son los siguientes: agregar global representa variables globales.
1) Verifique el número de ejecuciones de declaraciones de selección:
muestre el estado [global] como 'com_select';
2) Verifique el número de ejecuciones de declaraciones de inserción:
muestre el estado [global] como 'com_insert';
3) Verifique el número de ejecuciones de declaraciones de actualización:
muestra el estado [global] como 'com_update';
4) Verifica el número de ejecuciones de declaraciones de eliminación:
muestra el estado [global] como 'com_delete';
5) Verifica la cantidad de conexiones que intentan conectarse a MySQL (si la conexión tiene éxito o no):
muestra el estado como 'conexiones';
6) Ver el número de subprocesos en la caché de subprocesos:
muestra el estado como 'threads_cached';
7) Ver el número de conexiones actualmente abiertas:
muestra el estado como 'threads_connected';
8 ) Ver la cantidad de subprocesos creados para manejar conexiones:
mostrar estado como 'threads_created';
9) Ver el número de subprocesos activados (no inactivos):
mostrar estado como 'threads_running';
10) Ver el número de bloqueos de tabla obtenidos inmediatamente:
mostrar estado como 'table_locks_immediate';
11) Ver no El número de bloqueos de mesa adquiridos inmediatamente. Si el valor es alto y tiene problemas de rendimiento, primero debe optimizar la consulta y luego dividir la tabla o usar la replicación:
muestre el estado como 'table_locks_waited';
12) Ver la cantidad de subprocesos que se han creado durante más de slow_launch_time segundos:
show estado como 'slow_launch_threads';
13) Verifique el número de consultas con un tiempo de consulta superior a long_query_time segundos:
muestre el estado como 'slow_queries';
14) Verifique el tiempo de ejecución de MySQL después de este inicio (unidad: segundos):
muestre el estado como 'uptime' 15 )
Verifique el costo de la consulta anterior
y muestre el estado como 'last_query_cost'
16) Vea la información del caché de la consulta
que muestre el estado como 'qcache%';

6. Ver el estado de ejecución del motor de almacenamiento
(1) SHOW ENGINE se utiliza para mostrar la información de ejecución actual del motor de almacenamiento, incluidos los bloqueos de tabla y la información de bloqueo de fila mantenida por las transacciones, el estado de espera de bloqueo de las transacciones, la espera de semáforo de subprocesos; solicitudes de E/S de archivos, estadísticas del grupo de búfer y otros datos.
(2) Consultar la versión de InnoDB
para mostrar variables como 'innodb_version'\G;
o seleccionar * de information_schema.plugins;
mysql> mostrar variables como 'innodb_version'\G;
*************** *********** 1. fila ****************************
Nombre_variable: innodb_version
Valor: 5.7.31 -34
1 fila en conjunto (0.01 seg)
Estado de consulta de InnoDB
Como se puede ver en la siguiente consulta, es el número promedio por segundo calculado en los últimos 47 segundos, es decir: los parámetros cambian dinámicamente durante cada consulta.

mysql> mostrar
estado del motor innodb\G;


** 1. fila ***************


Tipo: InnoDB
Nombre:
Estado:

================

2022-06-27 09:33:40 0x
7fa1c8a5f700
SALIDA DEL MONITOR INNODB

================

Promedios por segundo
calculados a partir de los últimos
47 segundos

HILO DE FONDO
(hilo de fondo)

SRV_Master_Thread Loops
: 13285067 SRV_ACTIVE , 0 SRV_SHUTDOWN ,
1060666
6 SRV_IDLE
SRV_MASTER_THREAD cada bucle Ejecución (activa, apagada, inactiva), en la que el aumento en el número de activos está relacionado con cambios de datos y no tiene nada que ver con la consulta . ##### Se puede ver en la diferencia entre srv activo y srv_idle . Al comparar los valores de activo e inactivo, se obtiene la carga general del sistema. Cuanto mayor sea el valor de activo, más ocupado estará el servicio. #####srv_master_ thread log es la cantidad de veces que Master Thread escribe el registro de rehacer ( registro de rehacer) en el disco





















SEMÁFOROS (Semáforo
)

OS WAIT ARRAY INFO:
recuento de reservas 57836
764 #####
Información de la matriz de espera del SO: recuento esperado (cuota de
ranuras de asignación de InnoDB)
OS WAIT ARRAY INFO:
recuento de señales 269276481
##### Información de
la matriz : recuento de señales (el hilo
obtiene la frecuencia de la señal a través de la matriz)
Giros compartidos de RW 0,
rondas 171890114, el sistema operativo
espera 34656067 ###
## Recuento de bloqueos compartidos de RW,
tiempos de sondeo, tiempo de espera
Giros sin RW 0, rondas
1245774156, espera del sistema operativo
18379769 ### ##
Recuento de bloqueo exclusivo de RW,
tiempos de sondeo, tiempo de espera
RW-sx gira 80621,
rondas 1707842, OS
espera 34552 #
####Recuento de sx (bloqueo de intención exclusiva
) de RW, sondeo
1890114.00
Rondas de giro por espera: 17
-compartido,
1245774156.00 RW-
excl, 21.18 RW-sx ##
### Cada ronda de giro por
espera muestra: Cada
sistema operativo espera la
ronda de bloqueo de giro mutex
...
La declaración anterior puede mostrar diversa información sobre la operación actual del motor de almacenamiento innodb. Puede encontrar los problemas actuales de MySQL. Siempre que sepa que MySQL proporciona dicha herramienta de monitoreo, puede consultarla en detalle cuando sea necesario.

  1. HILO DE FONDO (hilo de fondo)
  2. SEMÁFOROS (Semáforo)
  3. ÚLTIMO BLOQUEO DETECTADO
  4. ACTAS
  5. ARCHIVO E/S
  6. INSERTAR BUFFER E ÍNDICE HASH ADAPTABLE (insertar búfer e índice hash adaptativo)
  7. REGISTRO
  8. BUFFER POOL AND MEMORY (grupo de búfer y memoria)
  9. OPERACIONES DE FILA

7. EXPLANAR plan de ejecución

A través del registro de consultas lentas, podemos saber qué sentencias SQL se ejecutan lentamente, pero ¿por qué es lenta? ¿Dónde está la lentitud?
MySQL proporciona un comando de consulta del plan de ejecución EXPLAIN. A través de este comando podemos ver el plan de ejecución de SQL.
EXPLAIN también se puede analizar para las declaraciones UPDATE, DELETE e INSERT después de MySQL 5.6.3, pero generalmente todavía lo usamos para consultas SELECT.
La optimización de SQL significa que no hay ningún problema con la sintaxis de SQL en sí, pero existe una mejor forma de escribir para lograr el mismo propósito. Por ejemplo:

使用小表驱动大表;用join改写子查询;or改成union
连接查询中,尽量减少驱动表的扇出(记录数),访问被驱动表的成本要尽量低,尽量在被驱动表的连接列上建立索引,降低访问成本;被驱动表的连接列最好是该表的主键或者是唯一二级索引列,这样被驱动表的成本会降到更低
大偏移量的limit,先过滤再排序

Tomemos un ejemplo simple para el último. Las siguientes dos declaraciones pueden lograr el mismo propósito, pero la eficiencia de ejecución de la segunda es mucho mayor que la de la primera (el motor de almacenamiento usa InnoDB). Vamos a sentirlo:
– 1. Consulta con desplazamiento grande
mysql> SELECT * FROM user_innodb LIMIT 9000000,10;
Conjunto vacío (8,18 seg)

– 2. Primero filtre la ID (porque la ID usa un índice), luego limite
mysql> SELECT * FROM user_innodb WHERE id > 9000000 LIMIT 10;
conjunto vacío (0,02 seg)

Optimización de índices
Crear índices apropiados para consultas lentas es un método muy común y muy efectivo, pero si el índice se usará de manera eficiente es otro tema.

4. Optimización del motor de almacenamiento y de la estructura de la tabla.

1. Seleccione el motor de almacenamiento

En circunstancias normales, elegiremos InnoDB, el motor de almacenamiento predeterminado de MySQL, pero cuando los requisitos de rendimiento de la base de datos mejoran constantemente, la elección del motor de almacenamiento también se convierte en un factor de influencia clave.

Para tablas comerciales con muchas operaciones de consulta y operaciones de inserción, se recomienda usar MyISAM; para
tablas temporales, use Memoria;
para empresas con gran concurrencia y muchas actualizaciones, elija InnoDB;
si no sabe qué elegir, simplemente elija el valor predeterminado.

2. Optimizar campos

El principio final de la optimización de campo es: utilice el tipo de datos más pequeño que pueda almacenar datos correctamente.
Tipo entero: diferentes tipos de almacenamiento tienen diferentes rangos de almacenamiento máximo y, naturalmente, ocupan diferentes espacios de almacenamiento
. Tipo de carácter: si no está seguro de la longitud de el campo, debe ser Elija varchar, pero varchar requiere espacio adicional para registrar la longitud actualmente ocupada por el campo; por lo tanto, si la longitud del campo es fija, intente usar char, lo que le ahorrará mucho espacio en la memoria.
No nulo: intente establecer los campos no nulos en NO NULL y proporcione valores predeterminados, o use valores especiales en lugar de NULL.
No use claves externas, activadores ni funciones de visualización.
Almacenamiento de imágenes, audio y video: no almacenar archivos grandes directamente; dirección de acceso de archivos grandes
División de campos grandes y redundancia de datos

5. Optimización empresarial

1. La optimización empresarial ya no es un medio para ajustar MySQL, pero la optimización empresarial puede reducir de manera muy efectiva la presión de acceso a la base de datos. Un ejemplo típico a este respecto es Taobao 1. En el pasado, las compras comenzaron en la noche del modelo Double 11, en los últimos
tiempos En los últimos años, el frente de preventa de Double 11 se ha vuelto cada vez más largo, comenzando con más de medio mes de anticipación, y han surgido sin cesar varios modelos de sobres rojos de depósito, este método se llama desvío de preventa. Esto puede desviar las solicitudes de servicio de los clientes, en lugar de esperar hasta la madrugada de Double Eleven para realizar pedidos colectivamente;
2. Durante Double Eleven, Alipay recomienda encarecidamente utilizar el pago Huabei en lugar del pago con tarjeta bancaria, aunque parte de la consideración es mejorar el La rigidez del software, pero por otro lado, el uso del servidor interno de Alibaba utilizado por Yu'ebao tiene una velocidad de acceso rápida, mientras que el uso de una tarjeta bancaria requiere llamar a la interfaz del banco, que es mucho más lento en comparación.

Insertar descripción de la imagen aquí

Supongo que te gusta

Origin blog.csdn.net/m0_57207884/article/details/130792829
Recomendado
Clasificación