Alguma ideia de por que adicionar uma classificação a esta consulta retorna consideravelmente mais rápido do que sem a ordem? Eu esperaria o contrário, então o que poderia fazer isso acontecer?
SELECT TOP (500) r.cID,r.aField,a.Description
FROM dbo.tblR r
inner join dbo.tblA a on r.aID = a.ID
left join dbo.tblX x on x.cID = r.cID
WHERE (ISNULL(x.anotherField,'') <> r.anotherField or x.field3 is null)
and (r.ID=(select max(ID) from tblR where cID = r.cID and
ISNULL(aField,'') <> ''))
and r.cID in (select ID from tblC)
ORDER BY r.cID ASC -- when I comment this line out it runs much slower
Os planos de execução não estão ajudando muito.
A causa mais óbvia seria aquela
(select max(ID) from tblR where cID = c.cID and ISNULL(aField,'') <> '')
subconsulta naWHERE
cláusula em combinação com oTOP 500
que está fazendo a ordem fazer diferença.Em ambos os casos, ele provavelmente executará essa subconsulta individualmente para cada linha que poderia retornar até encontrar 500 que correspondam ao todo
WHERE
(na verdade, será claro o suficiente para verificar as outras partes do WHERE primeiro, pois elas são muito mais barato, mas ainda estará executando a subconsulta para uma parte das linhas que encontrar). Em um palpite, mais linhas perto do topo quando classificadas por c.cID correspondem atualmente, então ele tem que executar a subconsulta com menos frequência antes de encontrar 500 correspondências do que ao executar os resultados na ordem que o planejador de consulta escolhe por padrão.(estou assumindo que o
c
s deveria serx
s ou vice-versa, caso contrário a consulta não seria executada porque o aliasc
não está definido em nenhum lugar)Vale a pena executar consultas como essa no Management Studio com a exibição "plano de consulta real" ativada - então você pode ver no diagrama quais partes estão causando o desempenho diferente.