Início / dba / Perguntas / 344548
Accepted
J. Mini
Asked: 2025-01-05 03:04:58 +0800 CST

Há algum benefício de desempenho em ter uma coluna de particionamento que não seja a primeira chave de um índice?

  • 772

Se você é bem lido sobre particionamento, então você estará completamente ciente de que particionamento não é um recurso de desempenho para índices rowstore. No entanto, sempre que vejo argumentos feitos para isso, como feito de forma mais convincente aqui por Gail Shaw , os argumentos dependem da comparação de um índice não particionado com um índice particionado onde ambos os índices têm a chave de particionamento como sua chave principal. Argumentos como o de Gail funcionam com base no fato de que há uma diferença mínima de desempenho entre a eliminação de partições e a busca por um índice não particionado com sua suposta chave de particionamento como a primeira chave.

Esses argumentos são convincentes, mas e os casos em que a chave de particionamento não é a primeira chave do seu índice particionado? Nesses casos, obtemos os benefícios da eliminação de partições e nossa chave principal agora é usada para pesquisar um índice consideravelmente menor do que teríamos se deixássemos o mesmo índice não particionado. Isso parece que deve dar uma melhoria de desempenho em relação a deixar o mesmo índice não particionado.

Em resumo, minha pergunta é esta: Há benefícios de desempenho em particionar um índice que tem várias chaves se a coluna de particionamento não for a primeira chave do índice? Tudo o que deve ser necessário para responder a essa pergunta é um exemplo acompanhado de alguma teoria explicando por que os resultados são como são.

sql-server

1 respostas

  1. Best Answer

    Há benefícios de desempenho no particionamento de um índice que tem várias chaves se a coluna de particionamento não for a primeira chave do índice?

    Sim. O SQL Server já pode executar varredura de intervalo com eficiência na coluna principal de um índice clusterizado. O particionamento nessa coluna não adiciona nada às opções do plano de consulta.

    No entanto, o particionamento por uma coluna final adiciona outro método de eliminação eficiente de dados. Um plano ainda pode buscar eficientemente usando a coluna inicial, mesmo que precise buscar em cada partição. Mas, além disso, um plano pode fazer eliminação de partição na coluna final.

    Considere um fato de vendas com uma chave agrupada de (CustomerID, ProductId, SalesDate)

    select CustomerID, sum(SalesAmount) SalesTotal
from sales 
where CustomerId = @id
and SalesDate >= @beginDate
and SalesDate < @endDate;

    seria mais barato se a coluna de particionamento fosse SalesDate em vez de CustomerId (ou não fosse particionada).

    O particionamento não é um recurso de desempenho, pois nem sempre ou normalmente melhora o desempenho, mas tem implicações de desempenho, tanto positivas quanto negativas.

    • 3

relate perguntas