Las consultas frecuentes a la base de datos MySQL provocan fallos.

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, el HDD IOPS de la biblioteca de desarrollo aquí es bajo, por lo que la velocidad de 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, el espacio de la tabla en realidad se verifica y, cuando se restaura, el espacio de la tabla se verifica nuevamente, lo que equivale a verificar dos veces. Sin embargo, MySQL 8.0 tiene una característica adicional, que es que cuando la cantidad de tablas supere 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 recuperación forzada para omitir páginas incorrectas. Puede omitir la verificación y luego reiniciar 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. Hasta ahora no he encontrado ningún peligro oculto. 2. Utilice * * * espacio de tabla compartido en lugar de espacio de tabla independiente, de modo que no sea necesario abrir n archivos ibd, solo es necesario abrir 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 de tablas grandes, siento que * * * el espacio de tabla compartido tiene más ventajas en muchos entornos empresariales.

Otra solución surgió temporalmente, que es usar GDB para depurar la recuperación de fallas. Al modificar temporalmente el valor de la variable de validación, MySQL omite el proceso de verificación del espacio de tabla y luego cierra MySQL normalmente y se reinicia 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. Sin embargo, 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 puede modificar la variable de validación y su idea se hace añicos.