Requisitos previos
El comando OPTIMIZE TABLE solo es compatible con los motores de almacenamiento InnoDB y MyISAM.
-
El espacio disponible en disco de la instancia debe ser mayor o igual que el tamaño de la tabla que desea optimizar.
Notas de uso
Elimine primero una gran cantidad de datos: ejecutar OPTIMIZE TABLE no reduce el uso del espacio de la tabla a menos que antes elimine una cantidad significativa de datos con el comando DELETE.
Aumento temporal del uso de espacio en disco: al ejecutar OPTIMIZE TABLE se crea una tabla temporal para almacenar los datos reorganizados, lo que incrementa temporalmente el uso del espacio en disco. Cuando termina la operación, se elimina la tabla temporal y el uso del espacio en disco vuelve a la normalidad.
Las estadísticas de la tabla y de los índices podrían no cambiar tras la recuperación: aunque se libere el espacio en disco, es posible que las estadísticas de la tabla no se actualicen de inmediato. Para obtener más información, consulte Why does the storage usage of my ApsaraDB RDS for MySQL instance remain unchanged after I run OPTIMIZE TABLE?.
Impacto en el rendimiento y riesgos durante las horas pico: en ApsaraDB RDS for MySQL 5.7 y 8.0, el comando OPTIMIZE TABLE utiliza DDL en línea, lo que permite operaciones DML simultáneas. Sin embargo, ejecutar esta operación en una tabla grande puede provocar picos repentinos en el consumo de recursos de E/S y de búfer. Esto genera bloqueos de tabla o contención de recursos, lo que podría causar indisponibilidad de la instancia o interrupciones en el monitoreo durante las horas pico. Por lo tanto, ejecute esta operación fuera de las horas pico para evitar afectar el negocio.
Uso de la línea de comandos
Connect to the ApsaraDB RDS for MySQL instance by using a client.
Utilice el comando DELETE para eliminar los datos innecesarios según los requisitos de su negocio.
-
Ejecute el comando OPTIMIZE TABLE para recuperar el espacio de la tabla.
OPTIMIZE TABLE <$Database1>.<Table1>,<$Database2>.<Table2>;
Nota
<$Database1> y <$Database2> son nombres de bases de datos. <Table1> y <Table2> son nombres de tablas.
-
Al ejecutar el comando OPTIMIZE TABLE en el motor de almacenamiento InnoDB, se devuelve el siguiente mensaje. Este comportamiento es normal y se puede ignorar. La operación es exitosa si la salida contiene "ok". Para obtener más información, consulte OPTIMIZE TABLE Statement.
Table does not support optimize, doing recreate + analyze instead
Uso de DMS
Log on to the ApsaraDB RDS for MySQL instance by using DMS.
En el panel de navegación izquierdo, seleccione el ID de la instancia de destino, haga doble clic en la base de datos correspondiente, haga clic derecho en cualquier nombre de tabla y luego seleccione batch operation table.
Seleccione las tablas cuyo espacio desea recuperar y luego elija .
En el cuadro de diálogo que aparece, confirme que la información sea correcta y haga clic en OK.
Preguntas frecuentes
¿Por qué **storage usage** no cambia después de ejecutar OPTIMIZE TABLE?
Problema
Después de eliminar una gran cantidad de datos mediante el comando DELETE y de ejecutar OPTIMIZE TABLE para recuperar el espacio de la tabla, tal como se describe en official ApsaraDB RDS for MySQL documentation, consulta el campo DATA_FREE en information_schema.tables y observa que el valor no se actualizó. Esto podría llevarlo a suponer que la operación terminó con errores y que el espacio en disco no se liberó.
Causa
El espacio real en disco ya se liberó, pero las estadísticas de la tabla de MySQL no se actualizan de inmediato. Este problema es común en instancias de ApsaraDB RDS for MySQL 5.6, 5.7 y 8.0 con una versión secundaria del motor anterior a 20250531. En estas versiones, ejecutar OPTIMIZE TABLE no actualiza automáticamente las estadísticas de la tabla ni de los índices. Como resultado, el valor de DATA_FREE en information_schema.tables conserva el valor anterior, lo cual no refleja con precisión el uso real del espacio. Para obtener más información, consulte Bug #117426: optimize table does not update table and index stats.
Solución
-
Solución recomendada: actualizar la versión secundaria del motor a 20250531 (para MySQL 8.0)
Este problema se corrigió en minor engine version 20250531 para ApsaraDB RDS for MySQL 8.0. Después de la actualización, OPTIMIZE TABLE actualiza automáticamente las estadísticas y el campo DATA_FREE refleja correctamente el uso real del espacio.
Solución temporal: forzar la actualización de estadísticas. Si no puede actualizar la versión de su base de datos a corto plazo, ejecute el comando ALTER TABLE table_name ENGINE=InnoDB; en la tabla que optimizó. Este comando fuerza la reconstrucción de la tabla y la actualización de sus estadísticas. Una vez ejecutado, el campo DATA_FREE en information_schema.tables muestra correctamente el espacio recuperado.
What to do if space is not released después de un comando DELETE?
En ApsaraDB RDS for MySQL, cuando se utiliza el comando DELETE para eliminar datos, este solo marca las ubicaciones de los registros o las páginas de datos como reutilizables. El tamaño del archivo en disco no cambia, lo que significa que el espacio de la tabla no se recupera de inmediato. Esto provoca fragmentación en el almacenamiento y consume espacio de la instancia.
Puede usar comandos DDL nativos o la función de cambio de esquema sin bloqueo en DMS. Tenga en cuenta que, antes de utilizar cualquiera de estos métodos, debe asegurarse de que la instancia tenga suficiente espacio en disco para evitar que se bloquee.
-
Desfragmentar el espacio mediante comandos: ejecute operaciones DDL como OPTIMIZE TABLE o ALTER TABLE <table_name> ENGINE=InnoDB; para reorganizar los datos de la tabla y las estructuras de índices, lo que recupera el espacio fragmentado.
Importante
Cuando utilice comandos DDL nativos, ejecútelos fuera de las horas pico para evitar bloqueos de metadatos. Para obtener más información, consulte Usage notes.
Usar la función de cambio de esquema sin bloqueo en DMS: para evitar problemas relacionados con los bloqueos de metadatos, utilice esta función para recuperar espacio de storage fragmentation.
¿Qué hacer si el espacio no se libera después de un comando **TRUNCATE o DROP**?
En ApsaraDB RDS for MySQL, si detecta que el espacio en disco no se libera después de ejecutar una operación TRUNCATE o DROP, siga estos pasos:
-
Confirmar la lógica de recuperación de espacio
Después de ejecutar un comando TRUNCATE o DROP, monitor the storage usage of the instance para confirmar si el espacio se liberó. Por lo general, la disminución en el uso de almacenamiento refleja el tamaño de la tabla eliminada en relación con el espacio total de la instancia.
-
Evitar depender de información desactualizada
Si comprueba el tamaño de la tabla mediante information_schema.tables o la consola de ApsaraDB RDS (), es posible que el espacio de tabla mostrado no cambie debido a retrasos en la actualización de los datos. Por lo tanto, utilice la métrica general de uso de almacenamiento de la instancia como criterio principal de evaluación.
-
Impacto de la eliminación asíncrona
Si la función de eliminación asíncrona (como la función Purge Large File Asynchronously de Alibaba Cloud) está habilitada en su instancia, el espacio ocupado por el archivo de la tabla no se libera de inmediato. En su lugar, un proceso en segundo plano lo libera de forma gradual. El espacio en disco se libera únicamente cuando este proceso termina.