Wenn willkürliche Einfügungen oder Löschungen in den Indizes einer Tabelle vorgenommen werden, können diese Indizes fragmentiert werden. Fragmentierung bedeutet, dass die physikalische Reihenfolge der Indexseiten auf der Platte nicht der Reihenfolge des Index für die Datensätze der Seiten entspricht, oder dass viele ungenutzte Seiten in den 64-Seiten-Blöcken vorhanden sind, die dem Index zugewiesen wurden.

Ein Fragmentierungssymptom liegt vor, wenn eine Tabelle mehr Platz belegt, als sie „sollte“. Wieviel mehr, das ist in der Praxis schwer zu sagen. Alle InnoDB-Daten und -Indizes werden in B-Bäumen gespeichert und ihr Füllfaktor kann zwischen 50% und 100% variieren. Ein anderes Symptom für Fragmentierung wäre es, wenn ein Tabellenscan wie dieser mehr Zeit braucht, als er „sollte“:

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

(In der obigen Anfrage „überlisten“ wir die SQL-Optimierung, damit sie statt des Sekundärindex den geclusterten Index durchsucht.) Die meisten Festplatten können 10 bis 50MB/s lesen. Anhand dieses Werts können sie einschätzen, wie schnell ein Tabellenscan eigentlich laufen sollte.

Index-Scans können schneller laufen, wenn Sie regelmäßig eine „Null“-ALTER TABLE-Operation durchführen:

ALTER TABLE tbl_name ENGINE=INNODB

Dies veranlasst MySQL, die Tabelle neu zu erstellen. Eine andere Möglichkeit für eine Defragmentierungsoperation wäre es, die Tabelle mit mysqldump in eine Textdatei zu dumpen, zu löschen und aus der Dump-Datei neu zu laden.

Wenn die Einfügungen in einen Index immer in aufsteigender Reihenfolge und Löschungen nur an seinem Ende stattfinden, garantiert der Dateiraumverwaltungs-Algorithmus von InnoDB, dass keine Fragmentierung in diesem Index auftreten kann.