Cobrindo índices quando colunas extras determinadas exclusivamente pelo índice em cluster

Question

Suponha que eu precise atualizar o mytab da Lutab da seguinte maneira

update myTab
  set LookupVale = (select LookupValue from luTab B
                                       where B.idLookup = myTab.idLookup)

Lutab consiste em 2 colunas (IdLookup (exclusivo), LookupValue)

O que é preferível: um índice em cluster exclusivo no IDLOOKUP ou um no IDLlookup e LookUpValue combinados? Um índice de cobertura fará alguma diferença nessa situação?

(Estou principalmente interessado no SQL Server)

---

Epílogo:

Segui os testes de Krips abaixo com 27m linhas em MyTab, 1,5m linhas em Lutab. A parte crucial parece ser a singularidade do índice. Se o índice for especificado como exclusivo, a atualização usará uma tabela de hash. Se não for especificado como exclusivo, a atualização primeiro agrava o Lutab by Idlookup (o fluxo Aggegate) e depois usa um loop aninhado. Isso é muito mais lento. Quando eu uso o índice estendido, o SQL agora não é mais assumido que esse lookupValue é único, de modo que é forçado pela rota de loop mais lentamente mais lenta e aninhada

Answer 1

Criei suas mesas e carreguei apenas alguns discos (mais ou menos 50 pesquisas e 15 no MyTab).

Então eu tentei várias opções de índice. O índice procurar no Lutab sempre tem um custo de 29%.

O bit interessante é que, se você adicionar a coluna LookupValue ao índice no Lutab, o plano de execução mostrar duas etapas extras após a busca do índice: agregado e afirmam. Embora o custo seja de 0%, isso pode aumentar com mais dados.

Eu também tentei um índice não clusterado apenas no IDLookup e incluindo o LookUpValue como uma 'coluna incluída'. Dessa forma, as páginas de dados não precisam ser acessadas para recuperar essa coluna. Isso pode ser uma opção para você, embora o plano de execução não mostre nada diferente (mas eles também não têm o fluxo agregado / afirmado).

-Krip

Answer 2

Primeiramente:

• Um índice de cobertura é sempre não agrupado
• Você sempre deve ter um PK e um índice em cluster (existem os mesmos por padrão no SQL Server)

Os 2 conceitos são separados

Então:

• Seu PK (em cluster) seria o IDLOOKUP se isso identificar uma linha exclusiva
• O índice de cobertura seria (IdLookup) incluir (LookUpValue)

No entanto:

• O IDLOOKUP é o PK (em cluster), então você não precisa de um índice de cobertura
• O índice em cluster (PK) é implicitamente "coberto" pela natureza de um índice em cluster (simplesmente, o índice é dados no nível mais baixo)