¿Cuál es la razón por la que la base de datos MySQL se ralentiza repentinamente?

Cuando MySQL se recupera de un fallo, revisa las páginas de encabezado de todos los archivos ibd para verificar la precisión del diccionario de datos. Si MySQL contiene una gran cantidad de tablas, este proceso de verificación llevará mucho tiempo. La recuperación de fallos en MySQL está relacionada con la cantidad de tablas. Cuanto mayor sea el número total de tablas, mayor será el tiempo de recuperación tras un fallo. Además, las IOPS del disco también afectan el tiempo de recuperación tras fallos. Por ejemplo, la biblioteca de desarrollo aquí tiene IOPS de HDD muy bajos, por lo que la verificación es muy lenta cuando se enfrenta a una gran cantidad de espacios de tabla. Otro descubrimiento es que cuando MySQL 8 está habilitado normalmente, en realidad verifica el espacio de tabla y, cuando se recupera, verifica el espacio de tabla nuevamente, lo que equivale a verificarlo dos veces. Sin embargo, MySQL 8.0 tiene una característica adicional, es decir, cuando la cantidad de tablas supera los 5 W, se habilitará el escaneo multiproceso para acelerar el proceso de verificación del espacio de tablas.

¿Cómo omitir la verificación? ¿Existe alguna manera de omitir el proceso de verificación del espacio de tabla durante la recuperación tras fallo en MySQL 5.7? Hay dos formas principales de verificar la información:

1. Configure innodb_force_recovery para habilitar srv_force_recovery. = 0, luego validar = falso, es decir, se puede omitir la verificación del espacio de tabla. En la prueba real, se configuró innodb_force_recovery =1, lo que significa que la recuperación forzada omite las páginas defectuosas, por lo que la verificación se puede omitir y luego reiniciar para comenzar normalmente. Este método temporal puede evitar el lento proceso de verificación del espacio de tabla después de la recuperación tras un fallo e iniciar MySQL rápidamente. Personalmente, hasta ahora no he encontrado ningún peligro oculto. 2. Utilice * * * espacio de tabla compartido en lugar de espacio de tabla independiente, por lo que no necesita abrir n archivos ibd, solo un archivo ibdata, lo que ahorra mucho tiempo de verificación. Después de escuchar la teoría del profesor Jiang sobre el uso de * * * espacio de tabla compartido en lugar de espacio de tabla independiente para resolver la fluctuación del rendimiento al eliminar tablas grandes, siento que * * * el espacio de tabla compartido tiene más ventajas en muchos entornos empresariales.

Ha surgido temporalmente otra solución, que consiste en utilizar GDB para depurar la recuperación de fallos, permitiendo a MySQL omitir el proceso de validación del espacio de tabla modificando temporalmente el valor de la variable de validación y luego apagando MySQL normalmente y reiniciando. normalmente. Sin embargo, las pruebas reales muestran que si ejecuta en modo de depuración, puede modificar temporalmente la variable de validación y omitir el proceso de verificación del espacio de tabla, pero la eficiencia de ejecución del código en modo de depuración se reduce considerablemente, pero lleva más tiempo. Sin embargo, si ejecuta en modo sin depuración, no podrá modificar las variables de validación y su idea fracasará.