テーブルのインデックスでランダムな挿入または削除が行われると、インデックスがフラグメント化される事があります。フラグメント化とは、ディスクでのインデックス ページの物理的な順序が、ページでのレコードのインデックス順とかけ離れている事、またはインデックスに割り当てられた64ページのブロック内に多数の未使用ページがある事を意味します。

フラグメント化の兆候は、テーブルが 「必要とする」 以上の領域を取るという事です。それがどの程度なのかという事を正確に決めるのは困難です。全ての InnoDB データとインデックスは B ツリー内に格納され、それらの充てん比は50% から100% で異なっています。

その他のフラグメント化の兆候は、このようなテーブルスキャンに 「必要」 以上の時間がかかるという事です。

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

(前出のクエリの中で、SQL オプチマイザはセカンダリ インデックスではなく、集合インデックスのスキャンの中で 「欺かれて」 います。)ほとんどのディスクが1秒に付き10から50 MB で読み込む事ができ、それでテーブル スキャンがどれくらいのスピードで起動しなければいけないかを概算します。

それは 「null」 ALTER TABLE 操作を定期的に実行すればインデックス スキャンの速度を上げる事ができます:

ALTER TABLE tbl_name ENGINE=INNODB

それによって MySQL はテーブルを再構成します。デフラグ操作を行う別の方法は、テーブルをテキスト ファイルにダンプし、テーブルをドロップし、そしてそれをダンプ ファイルから再ロードする為に mysqldump を利用する事です。

インデックスへの挿入が常に昇順で行われ、レコードが必ず末尾から削除される場合は、InnoDB のファイル領域管理アルゴリズムによってインデックスのフラグメント化が発生しない事が保証されます。