Si se producen inserciones o eliminaciones aleatorias en los índices de una tabla, los índices pueden resultar fragmentados. Esto significa que el orden físico de las páginas de índice en el disco no guarda relación con el orden de los registros en las páginas, o que hay muchas páginas en blanco en los bloques de 64 páginas que se asignan al índice.

Un síntoma de la fragmentación es que una tabla ocupa más espacio del que 'debería' ocupar. Es difícil determinarlo con exactitud, ya que todos los datos e índices en InnoDB se almacenan en estructuras B-tree, cuya porporción de espacio ocupado (fillfactor) puede variar entre el 50% y el 100%. Otro síntoma de fragmentación es que una consulta que examine toda la tabla:

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

toma más tiempo del que debería. (En la consulta anterior, se ha “engañado” al optimizador SQL para que examine el índice agrupado, no un índice secundario). La mayoría de los discos pueden leer entre 10 y 50 MB por segundo. Esto puede usarse para estimar la velocidad con que debería examinarse una tabla.

Se puede acelerar el examen de los índices si periódicamente se lleva a cabo una operación ALTER TABLE “neutra”:

ALTER TABLE tbl_name ENGINE=INNODB

Esto provoca que MySQL reconstruya la tabla. Otra forma de ejecutar una desfragmentación es emplear mysqldump para obtener un volcado de la tabla en un fichero de texto, eliminar la tabla, y volver a crearla a partir del fichero de volcado.

Si las inserciones en un índice se producen siempre en orden ascendente y los registros se eliminan solamente desde el final, el algoritmo de gestión de espacio en fichero que tiene InnoDB garantiza que no se produzca la fragmentación del índice.