Indicies clusterizados vs Indices naoclusterizadosIndices clusterizados: Cada tabela so pode conter apenas um indiceclusterizado. Os indices clusterizados fornecem uma ordem declassificacao para o armazenamento de dados dentro de uma tabela, mas naofisicamente pois, geraria grande volume de I/O (Entrada e saida de disco). Em geral toda tabela deve ter um indicieclusterizado, normalmente definimos como chave primaria. Um dos principais objetivos de um indicie clusterizado eeliminar os ponteiros de encaminhamento. Lembra-se da estrutura B-Tree? Casonao tenha lido, recomendo o artigo: Estrutura B-Tree, resumindo, as informacoes saoarmazenadas nas folhas e para que o SGDB busque as informacoes, sao'rastreadas' pelas chaves de indicie que e o numeral que indica o numero dalinha em questao. Existem algumas restricoes para os indiciesclusterizados: Podem ter 900 Bytes na chave de indicie e no maximo 16colunas. Por padrao, o SQL Server cria indicie clusterizado exclusivo para a chaveprimaria.Indices nao clusterizados: Os indices nao clusterizados nao impoem umaordem de classificacao na tabela. Podem-se criar varios indicies naoclusterizados dentro de uma tabela e como os indices clusterizados, podem terno maximo 900 Bytes na chave de indice e no maximo 16 colunas. Se existe um indice clusterizado na tabela, o indice naoclusterizado possuem ponteiros que apontam para o indice a chave de cluster. Senao existe indice clusterizado, o indicie nao clusterizado aponta para a linhade dados na tabela. Isto faz com que seja feita mais uma operacao necessariapara localizar dados dentro de uma linha na tabela degradando um pouco a desempenhoem comparacao a tabela existir um indice clusterizado.Performance: Podemos imaginar que podemos entao encher uma tabela com indicesja que sao tao formidaveis assim.Nao e bem por ai, cada linha adicionada em uma tabela ou excluida, fara com queo SGDB reconstruia o indicie na arvore B-Tree. Se houver um estouro de pagina,havera a divisao de niveis e o SGDB tera que recalcular e alocar as chaves deindicies nas paginas da estrutura B-Tree. Embora sejam eficientes para consultas SQL, temos estarestricao de recriacao de estrutura de dados B-Tree quando ocasionamosoperacoes de INSERT, UPDATE, DELETE. Nos bancos OLTP isso pode ser bastante prejudicial devido aquantidade de transacoes no banco, entao cada indice criado temos que analisarsuas intencoes dentro da tabela e ver se realmente ele e necessario e testar oqual o ganho que podemos ter. Dentro de bancos OLAP, como o nivel de transacoes sao baixos e ainsercao de dados e normalmente atraves de operacoes em lote e agendada emhorarios com baixa incidencia de consultas, e bastante interessante ter varios indicesnas colunas mais acessadas. Prezados leitores,para melhor comodidade estamos mudando o blog para o link abaixo:http://hudsondatablog.wordpress.com/Espero que o visual seja mais limpo. O campo de pesquisa por palavras funciona que e uma beleza. No menu de categorias e de facil navegacao.Espero que gostem.Novidades toda semana. Para falarmos dos indicies primeiramente precisamos entender a estrutura de busca de um SGDB a informacao. A estrutura de busca por indicies das principais ferramentas de SGDB do mercado usa uma arquitetura de busca mais conhecida com B-Tree. A arquitetura de busca B-Tree se baseia em um conceito de paginas de alocacao de dados.Vejamos a figura abaixo: Nota-se claramente que