Uma tabela clusterizada é uma B-Tree sem porção "heap" - as linhas são armazenadas diretamente na estrutura B-Tree do índice de clustering (chave primária). Os nós da B-Tree podem ser divididos ou unidos, de modo que a localização física ou as linhas podem ser alteradas, portanto, não podemos ter um "ponteiro" simples de um índice secundário para as linhas, portanto, o índice secundário deve incluir uma cópia completa de os campos de índice primários para poder identificar as linhas de forma confiável.

Isso vale para Oracle, MS SQL Server e também vale para InnoDB .

O que significa que índices secundários em tabelas clusterizadas são "mais gordos" do que índices secundários em tabelas baseadas em heap, que:

• reduz o agrupamento de dados,
• reduz a eficácia do cache,
• torna a manutenção mais cara,
• e, o mais importante, tem consequências no desempenho da consulta:
  • Consultar um índice secundário pode exigir uma pesquisa dupla - uma pesquisa no índice secundário para localizar os dados "chave" e outra no primário, para localizar a própria linha (o Oracle tem algumas otimizações interessantes para evitar a segunda pesquisa, mas O InnoDB não, que eu saiba).
  • Por outro lado, o índice secundário naturalmente cobre mais campos, de modo que a segunda pesquisa poderia ser evitada por completo onde um índice tradicional baseado em heap exigiria um acesso à tabela. No entanto, o mesmo efeito pode ser obtido no índice baseado em heap, simplesmente adicionando mais campos a ele.

Deixe-me citar Use o índice, Luke!

a> :"As vantagens de tabelas organizadas por índice e índices clusterizados são principalmente limitadas a tabelas que não precisam de um segundo índice."

O que é uma pena, já que o MySQL não permite que você escolha o cluster independentemente do mecanismo de armazenamento.