Sou iniciante em SQL e Administração de Banco de Dados e estou tentando entender a diferença entre índices clusterizados e não clusterizados. Mais ou menos eu entendi quais são as diferentes tarefas, mas tenho alguns problemas quando se trata da questão dos "ponteiros". Eu não venho de CS então tenho algum problema em imaginar o que acontece no "nível folha" com os ponteiros e de que forma eles conectam o índice aos dados. Então, o que significa que um índice clusterizado não armazena ponteiros para os dados, enquanto o não clusterizado armazena?
Desculpe antecipadamente se essas perguntas parecem estúpidas, mas neste momento estou bastante confuso!
Não, essa não é uma pergunta ruim.
No MS SQL Server (e outros que funcionam de maneira semelhante), um índice clusterizado não armazena ponteiros para os dados porque não precisa , um índice clusterizado na verdade contém os próprios dados da tabela .
Um índice clusterizado é a tabela, apenas ordenada de uma maneira particular.
Se você criar e preencher uma nova tabela sem índice clusterizado (chamado de "heap") e adicionar um índice não clusterizado , estará criando um novo objeto (ordenado) que ainda precisa apontar para as linhas no mesa .
Mas se você pegar esse heap e adicionar um índice clusterizado, estará literalmente reordenando a própria tabela .
Um heap é apenas um monte de páginas com linhas, não há realmente nenhuma informação sobre onde está o SQL Server mantendo o controle de "essa tabela é representada por esta lista de páginas". Para encontrar qualquer coisa, ele precisa escanear todo o lote (a menos que você use
TOP 1ouTOP <n>ouOFFSET/FETCHnesse caso ele pode escanear até que linhas suficientes sejam encontradas).Um índice é uma estrutura de árvore que torna a localização de coisas muito mais rápida do que a varredura de tudo. Não entrarei em detalhes sobre estruturas de índice/árvore (veja o golpe para uma referência útil), mas usar um índice significa que você pode encontrar uma coisa específica em apenas algumas leituras de página em vez de muitos milhares. As árvores têm um nó raiz na parte superior, nós folha na camada inferior e nós de ramificação no meio.
Um índice não clusterizado em um heap no SQL Server tem em seus nós folha referências para onde os dados estão no banco de dados: o arquivo, a página e o número da linha nessa página. Então, uma vez que você chega ao final da árvore, você ainda tem que ler a página, potencialmente uma por linha encontrada, se houver muitas correspondências.
Um índice clusterizado no SQL Server (o termo significa algo um pouco diferente no postgres e em outros lugares) contém os dados reais da linha nos nós folha: não são necessárias pesquisas extras. É por isso que os índices clusterizados são particularmente úteis para consultas de intervalo: você pode encontrar os dados de várias, talvez algumas centenas de linhas que correspondam ao filtro, todas na mesma página, portanto, não há mais pesquisas a serem feitas.
Um índice não clusterizado em uma tabela com um índice clusterizado é muito semelhante a um em um heap. A diferença é que, em vez dos nós folha contendo ponteiros para onde os dados estão no heap, eles contêm a chave de cluster para a linha para que os dados extras possam ser encontrados por meio do índice clusterizado (a menos que tudo o que você precisa esteja contido nos valores indexados, os
INCLUDEDvalores e a chave de clustering, caso em que não são necessárias mais pesquisas).Pode parecer que um índice não clusterizado em uma tabela clusterizada pode ser menos eficiente do que em uma não clusterizada, mas a pesquisa no índice clusterizado será apenas uma página ou poucas e existem outros fatores que podem tornar o pesquisa de heap é menos eficiente do que ler a página apontada pelo índice, e heaps também podem ser ineficientes de outras maneiras.
Consulte os documentos oficiais em https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-index-design-guide#Clustered para obter mais detalhes e alguns diagramas. Ou se você tiver um pouco de tempo para aprender brincando, experimente o How To Think Like SQL Server de Brent Ozar .