Um índice, agrupado ou não agrupado, pode ser usado pelo otimizador de consulta se e somente se a chave mais à esquerda no índice for filtrada. Portanto, se você definir um índice nas colunas (A, B, C), uma condição WHERE em [email protected] , em [email protected] ou em [email protected] AND [email protected] não alavancará totalmente o índice (veja a nota). Isso se aplica também às condições de associação. Qualquer filtro WHERE que inclua A considerará o índice:[email protected] ou [email protected] AND [email protected] ou [email protected] AND [email protected] ou [email protected] AND [email protected] AND [email protected] .

Então, no seu exemplo, se você fizer o índice clusterizado em part_no como a chave mais à esquerda e, em seguida, uma consulta procurando um part_id específico não use o índice e um índice não clusterizado separado deve existir em part-id .

Agora sobre a questão de qual dos muitos índices deve ser o agrupado 1. Se você tiver vários padrões de consulta que têm aproximadamente a mesma importância e frequência e se contradizem em termos das chaves necessárias (por exemplo, consultas frequentes por ou part_no ou part_id ), então você leva outros fatores em consideração:

• largura :a chave de índice clusterizado é usada como chave de pesquisa por todos outros índices não agrupados. Portanto, se você escolher uma chave ampla (digamos, duas colunas de identificador único), estará tornando todos os outros índices mais amplos, consumindo mais espaço, gerando mais IO e desacelerando tudo. Portanto, entre chaves igualmente boas do ponto de vista de leitura, escolha a mais estreita como agrupada e torne as mais amplas não agrupadas.
• contenção :se você tiver padrões específicos de inserção e exclusão tente separá-los fisicamente para que ocorram em diferentes partes do índice clusterizado. Por exemplo. se a tabela funcionar como uma fila com todas as inserções em uma extremidade lógica e todas as exclusões na outra extremidade lógica, tente fazer o layout do índice clusterizado para que a ordem física corresponda a essa ordem lógica (por exemplo, ordem de enfileiramento).
• particionamento :se a tabela for muito grande e você planeja implantar o particionamento, a chave de particionamento deve ser o índice clusterizado. Um exemplo típico são dados históricos que são arquivados usando um esquema de particionamento de janela deslizante. Mesmo que as entidades tenham uma chave primária lógica como 'entity_id', o índice agrupado é feito por uma coluna de data e hora que também é usada para a função de particionamento.
• estabilidade :uma chave que muda com frequência é um candidato ruim para uma chave clusterizada, pois cada uma atualiza o valor da chave clusterizada e força todos índices não clusterizados para atualizar a chave de pesquisa que eles armazenam. Como uma atualização de uma chave clusterizada provavelmente também realocará o registro em uma página diferente, isso pode causar fragmentação no índice clusterizado.

Observação:não totalmente alavancar, pois às vezes o mecanismo escolherá um índice não clusterizado para verificar em vez do índice clusterizado simplesmente porque é mais estreito e, portanto, tem menos páginas para varrer. No meu exemplo, se você tiver um índice em (A, B, C) e um filtro WHERE em [email protected] e os projetos de consulta C , o índice provavelmente será usado, mas não como uma busca, como uma varredura, porque ainda é mais rápido que uma varredura em cluster completa (menos páginas).