optimize y check table mysql

Question

Tengo una base de datos utilizada para estadísticas, con más de 2000 tablas, cada una con ~ 100 millones de filas.

Creo que algunas veces a la semana sería bueno comprobar las tablas para asegurarse de que son saludables, y si no, repararlas y optimizarlas.

El 60% de las tablas se actualizan todos los días, y el resto son archivos.

Mi pregunta es acerca de check(repair)/optimize: ¿Es bueno comprobar el estado de la tabla y optimizarlos algunas veces a la semana para asegurarse de que el sistema funcione sin problemas?

Answer 1

general que necesita para optimizar mesa cuando su archivo de datos está demasiado fragmentado en el disco (herramientas de uso para el sistema de archivos para comprobar - la secuencia de comandos vinculados por GiantRobot no calcula la fragmentación), cuando hubo muchas filas actualizadas y cambió su tamaño (lo que crearía una fragmentación de fila) o después de eliminar muchos registros cuando no los va a volver a agregar pronto. Debido a que MySQL utiliza espacio libre para nuevas filas, cuando los registros eliminados y nuevos tienen el mismo tamaño de fila, no es necesario OPTIMIZAR.

CHECK TABLE se usa solo cuando sospecha que hay daños en los datos (que no deberían ocurrir durante la ejecución normal). Algunas distribuciones de Linux (Debian, por ejemplo) tienen scripts de inicio que ejecutan CHECK TABLE para todas las tablas en el inicio del servidor MySQL. REPAIR TABLE se usa para reparar las tablas dañadas.

ANALYZE TABLE se puede utilizar para actualizar la cardinalidad del índice, que se utiliza para determinar el plan de ejecución de la consulta. Por lo general, solo se necesita en casos especiales.

No está claro por su pregunta cómo se usan sus tablas de estadísticas ... ¿cuántas escrituras, eliminaciones y lecturas? Mis tablas de estadísticas tienen escrituras todo el tiempo, y una vez al día se leen, los datos se consolidan y se escriben en otra tabla, luego se eliminan. En tal caso, no es necesario ejecutar OPTIMIZE ya que los datos no se leen con frecuencia y el espacio libre se reutiliza para nuevos datos. Estoy usando partición por día, así que en lugar de eliminar los registros (que es bastante lento) simplemente DROP PARTITION (que toma 1 seg máximo)

Answer 2

¡2000 mesas y 100 millones de filas parecen enormes! si intenta optimizar cada tabla varias veces por semana, durante la optimización, las tablas estarán bloqueadas, por lo que no podrá escribirlas hasta que termine el trabajo aquí hay un script que solo comprueba las tablas fragmentadas (% 60 de sus tablas, probablemente) y optimice solo las fragmentadas, avísenos si funciona.

Nota: No pude probar el script porque uso Windows Machine para mi proyecto actual. Leer los comentarios y las notas a continuación la secuencia de comandos para el enlace que he proporcionado

Optimize only fragmented tables in MySQL

Answer 3

La reparación es muy lenta con tablas grandes; probablemente debería evitar tablas muy grandes, especialmente con muchos índices, con MyISAM. Prefiera dividirlos en su lugar para reducir los tiempos de reparación. Esto puede requerir un cambio importante en el código de su aplicación.

También puede ver los problemas con la reparación here