Indices (o poder da busca). Parte II

Indicies clusterizados vs Índices não clusterizados

Índices clusterizados:

     Cada tabela só pode conter apenas um índice clusterizado.
     Os índices clusterizados fornecem uma ordem de classificação para o armazenamento de dados dentro de uma tabela, mas não fisicamente pois, geraria grande volume de I/O (Entrada e saída de disco).
      Em geral toda tabela deve ter um indicie clusterizado, normalmente definimos como chave primaria.

     Um dos principais objetivos de um indicie clusterizado é eliminar os ponteiros de encaminhamento. Lembra-se da estrutura B-Tree? Caso não tenha lido, recomendo o artigo: Estrutura B-Tree, resumindo, as informações são armazenadas nas folhas e para que o SGDB busque as informações, são 'rastreadas' pelas chaves de indicie que é o numeral que indica o numero da linha em questão.
 
      Existem algumas restrições para os indicies clusterizados: Podem ter 900 Bytes na chave de indicie e no máximo 16 colunas. 
Por padrão, o SQL Server cria indicie clusterizado exclusivo para a chave primaria.

Índices não clusterizados:

      Os índices não clusterizados não impõem uma ordem de classificação na tabela. Podem-se criar vários indicies não clusterizados dentro de uma tabela e como os índices clusterizados, podem ter no máximo 900 Bytes na chave de índice e no máximo 16 colunas.

    Se existe um índice clusterizado na tabela, o índice não clusterizado possuem ponteiros que apontam para o índice a chave de cluster. Se não existe índice clusterizado, o indicie não clusterizado aponta para a linha de dados na tabela. Isto faz com que seja feita mais uma operação necessária para localizar dados dentro de uma linha na tabela degradando um pouco a desempenho em comparação a tabela existir um índice clusterizado.


Performance:

    Podemos imaginar que podemos então encher uma tabela com índices já que são tão formidáveis assim.
Não é bem por ai, cada linha adicionada em uma tabela ou excluída, fará com que o SGDB reconstruía o indicie na arvore B-Tree. Se houver um estouro de pagina, haverá a divisão de níveis e o SGDB terá que recalcular e alocar as chaves de indicies nas paginas da estrutura B-Tree.

    Embora sejam eficientes para consultas SQL, temos esta restrição de recriação de estrutura de dados B-Tree quando ocasionamos operações de INSERT, UPDATE, DELETE.

   Nos bancos OLTP isso pode ser bastante prejudicial devido à quantidade de transações no banco, então cada índice criado temos que analisar suas intenções dentro da tabela e ver se realmente ele é necessário e testar o qual o ganho que podemos ter.
    Dentro de bancos OLAP, como o nível de transações são baixos e a inserção de dados é normalmente através de operações em lote e agendada em horários com baixa incidência de consultas, é bastante interessante ter vários índices nas colunas mais acessadas.