All Products
Search
Document Center

ApsaraDB RDS:Use the OPTIMIZE TABLE command to release tablespace for an ApsaraDB RDS for MySQL instance

Last Updated:Mar 28, 2026

When you use the DELETE statement to remove a large amount of data from a MySQL table, the disk space is not released directly. The statement only marks database records or data pages as reusable. To reclaim tablespace and reduce disk usage, run the OPTIMIZE TABLE command.

Prerequisites

Before you begin, ensure that you have:

  • A table that uses the InnoDB or MyISAM engine. Only these two engines support the OPTIMIZE TABLE statement.

  • Remaining disk space on the instance that is greater than or equal to the size of the table you want to optimize.

If the remaining disk space is insufficient, first scale out the disk space. After the operation completes, scale in the disk space as needed. The system refunds the price difference.

Considerations

  • Delete data first. OPTIMIZE TABLE does not effectively reduce tablespace usage unless you first delete a large amount of data using the DELETE statement.

  • Disk usage increases temporarily. MySQL creates a temporary table to store the reorganized data during the operation. After the operation completes, the temporary table is deleted and disk usage returns to normal.

  • Table and index statistics may not update immediately. The disk space is released, but MySQL table statistics are not refreshed promptly. For details, see Why does disk space appear unchanged after OPTIMIZE TABLE?

  • Run during off-peak hours. In ApsaraDB RDS for MySQL 5.7 and 8.0, OPTIMIZE TABLE uses the online DDL method, which supports concurrent DML operations. However, running this command on a large table can cause I/O and buffer resource usage to burst, leading to table locking or resource contention. During peak hours, the instance may become unavailable or monitoring may be interrupted.

Run OPTIMIZE TABLE from the command line

  1. Connect to the ApsaraDB RDS for MySQL instance from a client.

  2. Delete unwanted data using the DELETE statement.

  3. Run OPTIMIZE TABLE to reclaim tablespace.

    OPTIMIZE TABLE <database_1>.<table_1>, <database_2>.<table_2>;

    Replace <database_1> and <database_2> with your database names, and <table_1> and <table_2> with your table names. Expected output for InnoDB tables When you run OPTIMIZE TABLE on an InnoDB table, the following output appears. This is normal and indicates the statement ran successfully — you can ignore this message. Verify that the Status column shows OK. For more information, see OPTIMIZE TABLE statement.

    +----------------+----------+----------+-------------------------------------------------------------------+
    | Table          | Op       | Msg_type | Msg_text                                                          |
    +----------------+----------+----------+-------------------------------------------------------------------+
    | mydb.mytable   | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
    | mydb.mytable   | optimize | status   | OK                                                                |
    +----------------+----------+----------+-------------------------------------------------------------------+

Run OPTIMIZE TABLE using DMS

  1. Log on to the ApsaraDB RDS for MySQL instance using DMS.

  2. In the navigation pane on the left, find and click the target instance. Double-click the destination database. Right-click a table and select Batch Operations.

  3. Select the tables for which you want to release space, then choose Table Maintenance > Optimize Table.

    Optimize Table in DMS

  4. In the dialog box, confirm the information and click Confirm.

FAQ

Why does disk space appear unchanged after OPTIMIZE TABLE?

The disk space is actually released. The apparent discrepancy is a statistics refresh issue, not a sign that the operation failed.

After OPTIMIZE TABLE runs, MySQL does not immediately update the table statistics in information_schema.tables. This means the DATA_FREE field continues to show the pre-optimization value and does not reflect the actual free space. This behavior affects ApsaraDB RDS for MySQL 5.6, 5.7, and 8.0 instances running a minor engine version earlier than 20250531. For technical background, see Bug #117426: optimize table does not update table and index stats.

Fix (MySQL 8.0): upgrade the minor engine version to 20250531

This issue is fixed in ApsaraDB RDS for MySQL 8.0 minor engine version 20250531. After upgrading, DATA_FREE correctly reflects the actual space after optimization.

Workaround (if you cannot upgrade immediately)

Run the following command on the optimized table to force a rebuild and refresh the statistics:

ALTER TABLE table_name ENGINE=InnoDB;

After the command runs, DATA_FREE in information_schema.tables correctly reflects the released space.

DELETE is not releasing disk space in RDS MySQL

Why is disk space not released after DELETE?

DELETE only marks record locations or data pages as reusable — it does not shrink the disk file. The freed positions become fragmentation that still consumes storage.

Before using either solution below, make sure the instance has enough free space. A storage-full instance gets locked and becomes unavailable.

  • Use DDL commands: Run OPTIMIZE TABLE or ALTER TABLE <table_name> ENGINE=InnoDB; to reorganize table data and index structures, releasing fragmented space. Run these commands during off-peak hours to avoid metadata locks blocking other operations.

  • Use DMS lock-free schema evolution: To avoid metadata locks entirely, use DMS lock-free schema evolution to reclaim fragmented space.

TRUNCATE or DROP is not releasing disk space in RDS MySQL

Why is disk space not released after TRUNCATE or DROP?

Check the actual disk usage through instance disk usage monitoring rather than information_schema.tables or the RDS console (Autonomy Service > Quick Diagnostics > Space Analysis). Both sources can show stale data due to update latency.

If disk usage also shows no change, check whether Purge Large File Asynchronously is enabled on the instance. When this feature is active, space from TRUNCATE or DROP is not released immediately — a background process cleans it up gradually. Wait for the background process to finish.

References

Reclaim space from table fragments