Principios y notas de optimización del rendimiento de MySQL:
1. MySQL asignará una memoria (sort_buffer) para cada hilo para ordenar. El tamaño de la memoria es sort_buffer_size
1> Si la cantidad de datos ordenados es menor que sort_buffer_size, la clasificación se hará en la memoria.2
> Si la cantidad de datos ordenados es demasiado grande para almacenar tantos datos en la memoria, se utilizará un archivo de disco temporal para ayudar la clasificación, también conocida como clasificación externa.3
> Cuando se usa la clasificación externa, MySQL se dividirá en varios archivos temporales separados para almacenar los datos ordenados y luego fusionará estos archivos en un archivo grande
2. mysql leerá los datos que cumplan con las condiciones para sort_buffer atravesando el índice y los clasificará rápidamente según el campo de clasificación
1> Si el campo de consulta no está incluido en el índice auxiliar, debe devolver el índice agrupado para recuperar los campos requeridos de acuerdo con la clave primaria del registro de índice auxiliar.2
> Este método causará IO aleatorio. En MySQL5.6 , se proporciona el mecanismo MRR, que cambiará el índice auxiliar. La clave principal del registro coincidente se saca y se ordena en la memoria, y luego se vuelve a la tabla
3> Crear un índice conjunto de acuerdo con la situación para evitar la pérdida de rendimiento causada Si está permitido, también puede crear un índice de cobertura para evitar volver a la mesa.
El principio de dos formas de clasificación:
Ordenar todos los campos
1. Lea todos los campos obligatorios en sort_buffer a través del índice
2. Ordene según el campo de clasificación
3. Devuelva el conjunto de resultados al cliente
Desventajas:
1. Como resultado, sort_buffer no puede almacenar una gran cantidad de datos, porque además del campo de ordenación, se almacenan otros campos y la eficiencia de uso de sort_buffer no es alta
. 2. Cuando la cantidad de datos que se van a ordenar es grande , habrá una gran cantidad de archivos temporales y el rendimiento de clasificación será muy alto.
Ventajas deficientes : MySQL dará prioridad a la clasificación de campo completo cuando la memoria sea lo suficientemente grande, porque este método evita una operación de retroceso de tabla en comparación con la clasificación de filas.
Ordenar por rowid
1. Controlando la longitud de los datos de fila ordenados para almacenar la mayor cantidad de datos posible en sort_buffer, max_length_for_sort_data
2. Solo los campos y las claves primarias que deben ordenarse se leen en sort_buffer y se ordenan según el campo de clasificación
3 . Según el orden ordenado, tome el id para volver a la tabla para recuperar los datos que desea obtener
4. Devolver el conjunto de resultados al cliente
Ventajas: mejor uso de la memoria sort_buffer para las operaciones de clasificación, minimizar el acceso al disco
Desventajas : la operación de regresar a la tabla es IO aleatoria, causará muchas lecturas aleatorias, no necesariamente menores que la clasificación de campo completo para reducir el acceso al disco
3. Devolver el número de filas tomadas por el cliente de acuerdo con el resultado ordenado
1. Los retrasos principales y en espera,
Es la diferencia entre el tiempo de finalización de ejecución de la misma transacción en la base de datos en espera y el tiempo de finalización de ejecución de la base de datos principal, incluido el tiempo de finalización de ejecución de la transacción de la base de datos principal y el binlog enviado a la base de datos en espera, la diferencia entre tiempo de finalización de la ejecución de la transacción de base de datos en espera. El tiempo de retraso de seconds_behind_master de cada transacción, hay un campo de tiempo en el binlog de cada transacción, que se utiliza para registrar el tiempo de escritura en la base de datos principal, y la base de datos en espera saca el valor del campo de tiempo de la transacción que se está ejecutando actualmente. y lo calcula y el sistema actual Diferencia horaria.
2. El origen del retraso entre activo y en espera:
①En primer lugar, en algunas condiciones de implementación, el rendimiento de la máquina donde se encuentra la base de datos en espera es peor que el rendimiento de la máquina donde se encuentra la base de datos principal. La razón es que se implementan varias bases de datos en espera en la misma máquina. A una gran cantidad de consultas provocará competencia por los recursos de io. La solución es la configuración "Doble 1", tanto el registro de rehacer como el binlog solo escriben el caché de página fs
②La presión de la base de datos en espera es alta, y la razón es que se realizan una gran cantidad de operaciones de consulta en la base de datos en espera, lo que consume una gran cantidad de CPU, lo que genera retrasos en la sincronización. La solución es utilizar un maestro y varios esclavos, y múltiples esclavos para reducir la presión de consulta de la copia de seguridad
③ Transacción grande, porque si la operación dml de una transacción grande hace que el tiempo de ejecución sea demasiado largo, el binlog de la transacción se envía a la base de datos en espera, y la base de datos en espera también debe ejecutarse durante tanto tiempo, lo que provoca el retraso de la principal y en espera.La solución es minimizar la transacción grande, como la operación de eliminación, utilizando el límite para eliminar en lotes, puede evitar transacciones grandes y reducir el alcance del bloqueo.
④ El ddl de una tabla grande hará que la biblioteca principal envíe su binlog ddl a la base de datos en espera, y la base de datos en espera analiza el registro de transferencia, sincroniza y envía el siguiente binlog dml. Es necesario esperar el bloqueo de escritura mdl del ddl para ser liberado, lo que provoca los retrasos principal y de espera.
3. Estrategia prioritaria de confiabilidad,
① Determine si el seconds_behind_master de la base de datos en espera B es menor que un cierto valor (por ejemplo, 5 segundos), continúe con el siguiente paso; de lo contrario, vuelva a intentar este paso.
② Cambie la biblioteca principal A al estado de solo lectura, es decir, establezca solo lectura en verdadero,
③ Juzgar el valor de seconds_behind_master de la base de datos en espera B hasta que este valor se convierta en 0; Cambiar la base de datos en espera B a legible y de escritura significa establecer solo lectura en falso; Cambiar la solicitud de negocios a la base de datos en espera, entiendo si el binlog enviado Hay múltiples transacciones en registro de transferencias, y el tiempo en el que la empresa no está disponible es el tiempo total en que se utilizan varias transacciones. Si la biblioteca principal se apaga en condiciones anormales, causará problemas. Si el tiempo de retraso entre la biblioteca en espera y la biblioteca principal es corto, la empresa se puede utilizar normalmente después de que se utiliza el registro de transferencia. Si el registro de transferencia no se ha ya se ha utilizado, cambiar a La base de datos de respaldo causará la transacción completada anteriormente, "pérdida de datos", pero es inaceptable en algunos escenarios comerciales.
4. Estrategia de usabilidad, problemas:
En double m, y binlog_format = mixed, dará lugar a inconsistencias de datos primarios y secundarios. Cuando se usa binlog de formato de fila, el problema de inconsistencia de datos es más fácil de encontrar, porque la fila binlog registra todos los valores del campo.
Hoy, la profesora también habló sobre la necesidad de tomar precauciones primero, la prevención probablemente sea a través de estos puntos:
1. Control y distribución de permisos (permisos de la base de datos y del servidor)
2.Hacer especificaciones de operación
3. Capacitación regular para el desarrollo
4. Crear una base de datos de respaldo retrasada
5. Hacer un buen trabajo de auditoría SQL, siempre que sea una declaración que cambie las operaciones en Los datos en línea (DML y DDL) deben ser auditados.
6. Haga una copia de seguridad. La copia de seguridad se divide en dos puntos.
(1) Si la cantidad de datos es relativamente grande, utilice la copia de seguridad física xtrabackup. Realice copias de seguridad completas de la base de datos con regularidad o copias de seguridad incrementales.
(2) Si la cantidad de datos es pequeña, use mysqldump o mysqldumper. Luego use binlog para restaurar o crear una forma maestro-esclavo para restaurar datos.
También es necesario hacer una copia de seguridad del archivo binlog con regularidad. También es
necesario comprobar periódicamente si el archivo de copia de seguridad está disponible. Si se produce un mal funcionamiento y es necesario restaurar los datos, el archivo de copia de seguridad no está disponible, lo que es aún más trágico.
Si se produce una operación de eliminación de datos, se puede recuperar desde los siguientes puntos:
1. Las declaraciones de mal funcionamiento de DML causan pérdida o falta de información. Puedes usar flashback, pero actualmente estamos usando myflash de Meituan, que también es una buena herramienta, y la esencia es la misma. Ambos analizan primero el evento binlog y luego lo revierten. Invertir eliminar para insertar, insertar para eliminar e invertir la imagen antes y después de la actualización. Por lo tanto, debe establecer binlog_format = row y binlog_row_image = full.
Recuerde que al restaurar datos, primero debe restaurar a una instancia temporal y luego restaurar de nuevo a la biblioteca principal.
2. Mal funcionamiento de la declaración DDL (truncar y soltar), porque la declaración DDL no importa si binlog_format es una fila o una declaración En el binlog, solo se registra la declaración, no la imagen, por lo que es relativamente más problemático restaurarlo. Los datos solo se pueden restaurar mediante una copia de seguridad completa + binlog de aplicaciones. Una vez que la cantidad de datos es relativamente grande, el tiempo de recuperación es particularmente largo.