14.2.14.3. Defragmenting a Table
If there are random insertions into or deletions from the
indexes of a table, the indexes may become fragmented.
Fragmentation means that the physical ordering of the index
pages on the disk is not close to the index ordering of the
records on the pages, or that there are many unused pages in the
64-page blocks that were allocated to the index.
A symptom of fragmentation is that a table takes more space than
it “should” take. How much that is exactly, is
difficult to determine. All InnoDB data and
indexes are stored in B-trees, and their fill factor may vary
from 50% to 100%. Another symptom of fragmentation is that a
table scan such as this takes more time than it
“should” take:
SELECT COUNT(*) FROM t WHERE a_non_indexed_column <> 12345;
(In the preceding query, we are “fooling” the SQL
optimizer into scanning the clustered index, rather than a
secondary index.) Most disks can read 10 to 50MB/s, which can be
used to estimate how fast a table scan should run.
It can speed up index scans if you periodically perform a
“null” ALTER TABLE operation:
ALTER TABLE tbl_name ENGINE=INNODB
That causes MySQL to rebuild the table. Another way to perform a
defragmentation operation is to use mysqldump
to dump the table to a text file, drop the table, and reload it
from the dump file.
If the insertions to an index are always ascending and records
are deleted only from the end, the InnoDB
filespace management algorithm guarantees that fragmentation in
the index does not occur.
