Estou começando a aprender um pouco sobre como analisar planos de execução e tornar as consultas mais eficientes
Considere estas duas consultas básicas
select distinct pat_id, drug_class, drug_name from rx
select pat_id, drug_class, drug_name from rx
e seus planos de execução
índice usado:
CREATE CLUSTERED INDEX [ix_overlap] ON [dbo].[rx]
(
[pat_id] ASC,
[fill_date] ASC,
[script_end_date] ASC,
[drug_name] ASC
)
Embora a primeira consulta supostamente tenha o custo mais alto por uma margem de 4:1, ela é executada mais rapidamente que a segunda. Por que um distinto simples adicionado à consulta adicionará o operador de correspondência de hash (o que suponho ser sempre ruim, correções são bem-vindas)? E por que ela tem o custo de consulta mais alto em relação à segunda consulta se for executada mais rapidamente?
A primeira consulta está usando um plano paralelo, o que significa que o "trabalho" foi dividido em várias tarefas executadas por vários threads. O tempo de CPU cumulativo foi, portanto, maior do que para o plano serial usado para sua segunda consulta.
Quanto ao motivo pelo qual o distinto faz com que o operador de correspondência de hash apareça no plano; uma operação de agregação ou classificação é necessária para determinar o
DISTINCT
resultado. @SQL_Kiwi pode aparecer com uma explicação mais aprofundada em breve, mas o operador de correspondência de hash é aparentemente preferido para conjuntos de resultados maiores.