Una tabla agrupada es un B-Tree sin una porción de "montón":las filas se almacenan directamente en la estructura B-Tree del índice de agrupación (clave principal). Los nodos del B-Tree se pueden dividir o fusionar, por lo que la ubicación física o las filas pueden cambiar, por lo que no podemos tener un "puntero" simple desde un índice secundario a las filas, por lo que el índice secundario debe incluir una copia completa de los campos de índice principal para poder identificar filas de manera confiable.
Esto es cierto para Oracle, MS SQL Server y también es cierto para InnoDB .
Lo que significa que los índices secundarios en las tablas agrupadas son "más gruesos" que los índices secundarios en las tablas basadas en montones, que:
- reduce la agrupación de datos,
- reduce la efectividad del caché,
- hace que su mantenimiento sea más caro,
- y, lo que es más importante, tiene consecuencias en el rendimiento de las consultas:
- La consulta a través de un índice secundario puede requerir una doble búsqueda:una búsqueda a través del índice secundario para ubicar los datos "clave" y otra a través del principal, para ubicar la fila en sí (Oracle tiene algunas optimizaciones interesantes para evitar la segunda búsqueda, pero InnoDB no lo hace, que yo sepa).
- Por otro lado, el índice secundario naturalmente covers más campos, por lo que la segunda búsqueda podría evitarse por completo donde un índice tradicional basado en montón requeriría un acceso a la tabla. Sin embargo, se puede lograr el mismo efecto en el índice basado en montón, simplemente agregando más campos.
Lo cual es una pena, ya que MySQL no le permite elegir el agrupamiento independientemente del motor de almacenamiento.
