すべてのプロダクト
Search
ドキュメントセンター

ApsaraDB RDS:OPTIMIZE TABLE を使用した MySQL テーブルスペースの再利用

最終更新日:Aug 21, 2026

DELETE ステートメントを使用して大規模な MySQL テーブルからデータを削除しても、ディスク領域はすぐには解放されません。代わりに、データベースはレコードまたはデータページを 再利用可能 としてマークするだけです。テーブルスペースを再利用し、ディスク使用量を削減するには、OPTIMIZE TABLE ステートメントを実行します。

前提条件

  • OPTIMIZE TABLE ステートメントは、InnoDB および MyISAM ストレージエンジンでのみサポートされています。

  • インスタンスの使用可能なディスク領域は、最適化するテーブルのサイズ 以上 である必要があります。

    説明

    使用可能なディスク領域が不十分な場合は、まずディスク領域を拡張してください。操作が完了した後、必要に応じて差額が返金されるスケールダウンが可能です。

使用上の注意

  • 最初に大量のデータを削除: DELETE ステートメントで大量のデータを最初に削除しない限り、OPTIMIZE TABLE を実行してもテーブルスペースの使用量を削減する効果はありません。

  • ディスク領域使用量の一時的な増加: OPTIMIZE TABLE を実行すると、再編成されたデータを格納するための一時テーブルが作成され、ディスク領域の使用量が一時的に増加します。操作が完了すると、一時テーブルは削除され、ディスク領域の使用量は通常の状態に戻ります。

  • 再利用後、テーブルとインデックスの統計は変更されない可能性: ディスク領域は解放されますが、テーブルの統計がすぐに更新されない場合があります。詳細については、「OPTIMIZE TABLE を実行した後、ApsaraDB RDS for MySQL インスタンスのストレージ使用量が変更されないのはなぜですか?」をご参照ください。

  • ピーク時間中のパフォーマンスへの影響とリスク: ApsaraDB RDS for MySQL 5.7 および 8.0 では、OPTIMIZE TABLE ステートメントは オンライン DDL を使用し、同時 DML 操作が可能です。ただし、大規模なテーブルでこの操作を実行すると、I/O およびバッファリソースの消費が急増する可能性があります。これにより、ピーク時間 中に テーブルロック や リソースの競合 が発生し、インスタンスが利用できなくなったり、モニタリングの中断 が発生したりする可能性があります。したがって、ビジネスへの影響を避けるため、この操作は オフピーク時間 に実行してください。

コマンドラインの使用

  1. クライアントを使用して ApsaraDB RDS for MySQL インスタンスに接続します。

  2. ビジネス要件に基づいて、DELETE ステートメントを使用して不要なデータを削除します。

  3. OPTIMIZE TABLE ステートメントを実行して、テーブルスペースを再利用します。

    OPTIMIZE TABLE <$Database1>.<Table1>,<$Database2>.<Table2>;
    説明
    • <$Database1> と <$Database2> はデータベース名です。<Table1> と <Table2> はテーブル名です。

    • InnoDB ストレージエンジンで OPTIMIZE TABLE ステートメントを実行すると、次のメッセージが返されます。このメッセージは想定内の動作であり、無視して問題ありません。出力に "ok" が含まれていれば、操作は成功です。詳細については、「OPTIMIZE TABLE ステートメント」をご参照ください。

      Table does not support optimize, doing recreate + analyze instead

DMS の使用

  1. DMS を使用して ApsaraDB RDS for MySQL インスタンスにログインします。

  2. 左側のナビゲーションペインで、対象のインスタンスのインスタンス ID を選択し、対象のデータベースをダブルクリックし、任意のテーブル名を右クリックして、[テーブルの一括操作] を選択します。

  3. 領域を解放するテーブルを選択し、[テーブルメンテナンス] > [テーブルの最適化] を選択します。テーブルの最適化

  4. 表示されるダイアログボックスで、情報が正しいことを確認し、[OK] をクリックします。

関連ドキュメント

テーブルの断片化から領域を再利用する

よくある質問

OPTIMIZE TABLE の実行後に ストレージ使用量 が変更されないのはなぜですか?

問題

ApsaraDB RDS for MySQL の公式ドキュメントの説明に従って、DELETE ステートメントで大量のデータを削除し、OPTIMIZE TABLE を実行してテーブルスペースを再利用した後、information_schema.tables の DATA_FREE フィールドをクエリすると、値が更新されていないことがわかります。これにより、操作が失敗し、ディスク領域が解放されなかったと誤解する可能性があります。

原因

実際のディスク領域は解放されていますが、MySQL のテーブル統計がすぐに更新されません。この問題は、マイナーエンジンバージョンが 20250531 より前の ApsaraDB RDS for MySQL 5.6、5.7、および 8.0 インスタンスでよく見られます。これらのバージョンでは、OPTIMIZE TABLE を実行しても、テーブルとインデックスの統計は自動的に更新されません。その結果、information_schema.tables の DATA_FREE 値は古い値のままであり、実際の領域使用量を正確に反映しません。詳細については、「Bug #117426: optimize table does not update table and index stats」をご参照ください。

ソリューション

DELETE ステートメントの実行後に 領域 が解放されない場合の対処法

ApsaraDB RDS for MySQL では、DELETE ステートメントを使用してデータを削除すると、コマンドはレコードの場所またはデータページを 再利用可能 としてマークするだけです。ディスクファイルのサイズは変わらず、テーブルスペースはすぐには再利用されません。これによりストレージの断片化が発生し、インスタンスのストレージ領域を消費します。

ネイティブ DDL コマンドまたは DMS のロックフリーのスキーマ変更機能を使用できます。 どちらの方法を使用する前にも、インスタンスがロックされるのを防ぐために、十分なディスク領域があることを確認してください。

  • コマンドを使用した領域のデフラグ: OPTIMIZE TABLE や ALTER TABLE <table_name> ENGINE=InnoDB; などの DDL 操作を実行してテーブルデータとインデックス構造を再編成し、断片化された領域を再利用します。

    重要

    ネイティブ DDL コマンドを使用する場合は、メタデータロックを避けるためにオフピーク時間中に実行してください。詳細については、「使用上の注意」をご参照ください。

  • DMS のロックフリーのスキーマ変更機能の使用: メタデータロックに関連する問題を回避するには、この機能を使用してストレージの断片化から領域を再利用します。

TRUNCATE または DROP ステートメントの実行後に領域が解放されない場合の対処法

ApsaraDB RDS for MySQL で、TRUNCATE または DROP 操作を実行した後にディスク領域が解放されないことが判明した場合は、次の手順に従ってください:

  1. 領域再利用ロジックの確認

    TRUNCATE または DROP ステートメントを実行した後、インスタンスのストレージ使用量をモニタリングして、領域が解放されたかどうかを確認します。通常、ストレージ使用量の減少は、削除されたテーブルのサイズとインスタンス全体の領域との相対的な関係を反映します。

  2. 古い情報に依存しない

    information_schema.tables または ApsaraDB RDS コンソール ([データベース自律サービス (DAS)] > [ワンクリック診断] > [領域分析]) を使用してテーブルサイズを確認した場合、データ更新の遅延が原因で、表示されるテーブル領域が変更されないことがあります。そのため、インスタンス全体のストレージ使用量メトリックを主な判断基準としてください。

  3. 非同期削除の影響

    インスタンスで 非同期削除 機能 (Alibaba Cloud の 大容量ファイルの非同期パージ機能など) が有効になっている場合、テーブルファイルが占有していた領域は すぐには解放されません。代わりに、バックグラウンドプロセス によって徐々にクリアされます。ディスク領域は、このプロセスが完了した後にのみ解放されます。