MySQL: ¿OPTIMIZAR LA TABLA necesitada en la tabla con columnas fijas?

Question

Tengo un script semanal que mueve los datos de nuestra base de datos en vivo y los coloca en nuestra base de datos de archivo, luego borra los datos que acaba de archivar de la base de datos en vivo. Dado que es una eliminación de tamaño decente (aproximadamente el 10% de la tabla se recorta), pensé que debería ejecutar OPTIMIZE TABLE después de esta eliminación.

Sin embargo, estoy leyendo esto desde la documentación de MySQL y no sé cómo interpretarlo: http://dev.mysql.com/doc/refman/5.1/en/optimize-table.html

"OPTIMIZE TABLE se debe utilizar si ha eliminado una gran parte de una mesa o si ha realizado muchos cambios en una tabla con filas de longitud variable (tablas que tienen columnas VARCHAR, VARBINARY, BLOB o TEXT). Las filas eliminadas se mantienen en una lista vinculada y las operaciones INSERT subsiguientes reutilizan las posiciones de fila antiguas. Puede utilizar OPTIMIZE TABLE para reclamar el espacio no utilizado y para desfragmentar el archivo de datos ".

La primera frase es ambigua para mí. ¿Significa que debe ejecutarlo si: A) ha eliminado una gran parte de una tabla con filas de longitud variable o si ha realizado muchos cambios en una tabla con filas de longitud variable O B) ha eliminado una gran parte de CUALQUIER tabla o si ha realizado muchos cambios en una tabla con filas de longitud variable

¿Tiene sentido? Entonces, si mi tabla no tiene columnas VAR, ¿debo ejecutarla todavía?

Si bien estamos en el tema - ¿hay algún indicador que me diga que una tabla está lista para una llamada OPTIMIZE?

También leo este http://www.xaprb.com/blog/2010/02/07/how-often-should-you-use-optimize-table/ que dice que ejecutar la tabla OPTIMIZE solo es útil para la clave principal. Si la mayoría de mis selecciones provienen de otros índices, ¿estoy desperdiciando esfuerzo en las tablas que tienen una clave sustituta?

¡Muchas gracias!

Answer 1

En su situación hipotética, no creo que la optimización periódica de la tabla suponga una diferencia apreciable.

Lo primero es lo primero, su segunda interpretación (B) de la documentación es correcta - "si ha eliminado una gran parte de CUALQUIER tabla O si ha realizado muchos cambios en una tabla con filas de longitud variable".

Si su tabla no tiene columnas VAR, cada registro, independientemente de los datos que contiene, ocupa exactamente la misma cantidad de espacio en la tabla. Si se borra un registro de la tabla y el DB elige reutilizar el área exacta donde se almacenó el registro anterior, puede hacerlo sin perder espacio ni fragmentar sus datos.

En cuanto a si OPTIMIZE solo mejora el rendimiento en una consulta que utiliza el índice de clave principal, esa respuesta casi seguro variará según el motor de almacenamiento en uso, y me temo que no podría responder ese.

Sin embargo, hablando de motores de almacenamiento, si termina utilizando OPTIMIZE, tenga en cuenta que no le gusta ejecutar en tablas InnoDB, por lo que el comando asigna a ALTER y reconstruye la tabla, que podría ser más costoso operación. De cualquier manera, la tabla se bloquea durante las optimizaciones, así que tenga mucho cuidado con cuándo la ejecuta.

Answer 2

Hay tantas diferencias entre MyISAM e InnoDB, estoy partiendo esta respuesta en dos:

MyISAM

• FIXED tiene alguna significado para MyISAM.
• "Las filas eliminadas se mantienen en una lista vinculada y las operaciones subsiguientes de INSERT reutilizan las posiciones de fila antiguas" se aplica a MyISAM, no a InnoDB. Por lo tanto, para MyISAM tablas con un lote de abandono, OPTIMIZE puede ser beneficioso.
• En MyISAM, VAR más DELETE/UPDATE conduce a la fragmentación.
• Debido a la lista vinculada y al VAR, una sola fila se puede fragmentar en el archivo de datos (.MYD). (De lo contrario, una fila MyISAM es contiguo en el archivo de datos.)

InnoDB

• FIXED no tiene ningún significado para las tablas InnoDB.
• Para VAR en InnoDB, hay "divisiones de bloque", no una lista vinculada.
• En un BTree, las divisiones del bloque se estabilizan en un promedio del 69%. Entonces, con InnoDB, casi cualquier abuso dejará la mesa no demasiado hinchada. Es decir, ELIMINAR/ACTUALIZAR (con o sin VAR) conduce a una "fragmentación" BTree más limitada.
• En InnoDB, los bloques vacíos (16 KB cada uno) se ponen en una "lista libre" para su reutilización; no se devuelven al sistema operativo.
• Los datos de InnoDB es ordenado por el PRIMARY KEY, por lo que la eliminación de una filaen una parte de la mesa hace no proporcionan espacio para una nueva fila en otra parte de la mesa. Pero cuando se libera un bloque, se puede usar en otro lugar.
• Dos bloques adyacentes que están medio vacíos se unirán, liberando así un bloque.

Tanto

• Si va a extraer los datos "viejos" (el 10%), a continuación, PARTITIONing es una mucho mejor manera de hacerlo. Ver my blog. Implica DROP PARTITION, que es instantáneo y devuelve el espacio al SO, más REORGANIZE PARTITION, que puede ser instantáneo.
• OPTIMIZE TABLE casi nunca vale la pena hacerlo.