Eu tenho uma tabela pequena, mas consultada ativamente no SQL Server que possui 94 linhas que são lidas e\ou atualizadas com frequência. O índice clusterizado se encaixa com segurança em uma página de 1 8 KB e possui um espaço vazio significativo nessa página. Isso me leva a acreditar que quaisquer atualizações futuras não o colocarão em uma segunda página.
Além do índice clusterizado, ao longo dos anos vários índices não clusterizados foram adicionados.
Minha pergunta é, em um nível conceitual, os índices não clusterizados podem melhorar o desempenho do SELECT? Se o SQL Server não puder ler menos de 1 página de dados por vez, qualquer leitura de índice não clusterizado poderá ser facilmente satisfeita lendo a única página para o índice clusterizado ou estou entendendo mal o conceito?
Eu não quero incluir a definição da tabela, mas aqui estão algumas estatísticas de sp_BlitzIndex nessa tabela mostrando seu uso:
ClusteredIndex Reads: 1 (1 scan) Writes:180,544,146
Nonclustered Index Reads: 0 Writes:103
Nonclustered Index Reads: 63,425,182 (57,447,576 seek 5,977,606 scan) Writes:180,544,146
Nonclustered Index Reads: 150,953,542 (150,953,542 seek) Writes:180,233,055
Nonclustered Index Reads: 0 Writes:311,091
O índice clusterizado não parece ser lido, mas acho que poderia sem os outros índices. Mais detalhes interessantes, sp_BlitzLock mostra 39 deadlocks neste banco de dados e todos os 39 envolvidos nesta pequena tabela, o que acho interessante.
Sim. Você tem várias cópias desta tabela (ou subconjuntos dela) e as atualizações precisam ser coordenadas em todas as cópias. O desempenho da consulta provavelmente não é aprimorado pelos índices não clusterizados, mas eles provavelmente são a causa de seus deadlocks.
Mas para o desempenho da consulta SELECT, os índices não agrupados não devem ajudar.