Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
EPUB - 7.5Mb
HTML Download (TGZ) - 7.2Mb
HTML Download (Zip) - 7.2Mb


14.10.4 テーブルのデフラグ

セカンダリインデックスへのランダムな挿入やセカンダリインデックスからのランダムな削除によって、インデックスが断片化される場合があります。断片化とは、ディスク上のインデックスページの物理的な順序がページ上のレコードのインデックス順序とかけ離れているか、またはインデックスに割り当てられた 64 ページのブロック内に未使用のページが多数存在することを示します。

断片化の 1 つの現象として、あるテーブルが占めている領域が、本来占めているはずの領域より大きいことがあります。それが正確にどの程度かを判定するのは困難です。InnoDB のデータとインデックスはすべて B ツリー内に格納され、それらのフィルファクタは 50% から 100% まで変動する可能性があります。断片化の別の現象として、次のようなテーブルスキャンにかかる時間が、本来かかるはずの時間より長いことがあります。

SELECT COUNT(*) FROM t WHERE non_indexed_column <> 12345;

前のクエリーでは、MySQL が、大きなテーブルに対してもっとも遅いタイプのクエリーであるフルテーブルスキャンを実行する必要があります。

インデックススキャンを高速化するために、MySQL にテーブルを再構築させる次のnull ALTER TABLE 操作を定期的に実行できます。

ALTER TABLE tbl_name ENGINE=INNODB

MySQL 5.6.3 の時点では、ALTER TABLE tbl_name FORCE を使用して、テーブルを再構築するnull変更操作を実行することもできます。以前は、FORCE オプションは認識されましたが、無視されました。

MySQL 5.6.17 の時点では、ALTER TABLE tbl_name ENGINE=INNODBALTER TABLE tbl_name FORCE の両方がオンライン DDL (ALGORITHM=COPY) を使用します。詳細は、セクション14.11.1「オンライン DDL の概要」を参照してください。

デフラグ操作を実行するための別の方法として、mysqldump を使用してテーブルをテキストファイルにダンプし、テーブルを削除してから、それをダンプファイルからリロードする方法があります。

インデックスへの挿入が常に昇順であり、かつレコードが末尾からしか削除されない場合は、InnoDB のファイル領域管理アルゴリズムにより、インデックス内の断片化は発生しないことが保証されます。


User Comments
  Posted by Robbie Lindsey on December 12, 2006
FYI: The above ALTER statement gets a syntax error in version 4.1.0-Alpha, but it works in 4.1.16-Production.
  Posted by Rick James on August 16, 2015
Defragmentation is almost never needed for InnoDB tables. Spend your time looking for other ways to speed up your queries.
Sign Up Login You must be logged in to post a comment.