No plano de consulta a seguir - https://www.brentozar.com/pastetheplan/?id=H1dwOCHed (tem 3 seções, a última é o problema), há um nó na parte inferior que consome 37% dos recursos . Este é o plano de consulta real, não o plano de consulta estimado. No entanto, a tabela a que ela faz referência não aparece, ao analisar as leituras lógicas por meio do Set Statistics IO. Isso inclui as 2 seções para ActivityFeedTeamCache e ActivityFeedCache.
No passado, consegui usar Logical Reads como um proxy muito bom para desempenho. Reduza as leituras lógicas e você terá feito a coisa certa para o desempenho.
No entanto, como nesse caso, não há leituras lógicas para os blocos que são os piores (ActivityFeedTeamCache, ActivityFeedCache, Locales), qual é um bom proxy para testar o desempenho? Só que o % de custo no Plano de Execução Real diminui?
O % de custo ainda é apenas uma estimativa, mesmo em um Plano de Execução Real. Você precisa observar as estatísticas de nível de origem da linha aqui para saber quanto tempo cada etapa levou.
A julgar pelo XML, 274ms foram levados até o ponto do hash join no nó 7, 72ms disso foi apenas a varredura de cluster do
Pk_TeamMembers
(nó 8) e 35ms foi até o Left Semi Join (nó 9). Isso significa que impressionantes 167ms foram usados apenas para executar a etapa Hash Join (provavelmente atribuindo memória para as 263.600 linhas dePk_TeamMembers
).Parece que você já tentou segmentar essa junção antes:
Você provavelmente deseja fazer um loop aninhado (externo) para esse índice. O planejador de consulta decidiu usar uma junção de hash porque acha que você obterá 59.000 linhas do outro lado dessa junção, quando na verdade você obtém 3.
Você tem escolhas
A dica seria como
A segunda escolha será particularmente difícil devido à complexidade de seus filtros de direção. Uma maneira de fazer isso seria inserir as linhas que correspondem aos seus principais filtros de condução e, em seguida, juntar-se a essa tabela temporária em sua consulta principal. Aqui, parece que você precisa juntar 3 das 5 tabelas primeiro para utilizar seus
@userId@
filtros de forma justa:Você também tem uma pesquisa de chave na tabela TeamMembers, isso está consumindo 14% do tempo de execução. Você deve tentar criar um índice de conversão melhor para evitar esse tipo de operador em um plano de execução.
A coluna ausente que poderia, por exemplo, ser adicionada no INCLUDE é IsSiemensOnsiteAdmin
Além disso, você deve considerar modificar este código para usar CTE em vez de fazer 2 vezes a mesma consulta para colunas diferentes