O plano Real completo está aqui.
Antes de executar o plano (porque estou depurando um plano que funciona mal), tenho este bloco de atribuições de variáveis:
DECLARE @Days INT = 180
DECLARE @DateRangeFrom DateTime = DATEADD(d, -@Days, getDate())
DECLARE @DateRangeTo DateTime = getDate()
DECLARE @FacilityID INT = 1010
DECLARE @Answer0 INT = 1879
DECLARE @Answer1 INT = 1949
DECLARE @Answer1SetID INT = 1607
DECLARE @Answer2 INT = 1907
DECLARE @Answer2SetID INT = 1593
Meu primeiro problema é com a pesquisa que estou realizando na tabela IRItemAnswer_Info (Node ID 19). Está se espalhando para o Tempdb, que já inicia a consulta com o pé errado. Ele está referenciando o IRItemAnswerInfo_DGItemID_AnswerSourceIDíndice, que é o índice correto, pois estou combinando em DGItemIDe AnswerSourceID, e retornando IncidentID. O índice é criado como
CREATE NONCLUSTERED INDEX IRItemAnswerInfo_DGItemID_AnswerSourceID
ON dbo.IRItemAnswer_Info (DGItemID, AnswerSourceID)
INCLUDE([IncidentID], [AnswerBoolean])
No entanto, as linhas estimadas para a consulta são 53.459 e as linhas reais são 969.812.
Acabei de forçar novas estatísticas via UPDATE STATISTICS IRItemAnswer_Info IRItemAnswerInfo_DGItemID_AnswerSourceID WITH FULLSCANe não fez diferença.
DBCC SHOW_STATISTICS ('IRItemAnswer_Info', 'DGItemID')para DGItemID=1949tem EQ_ROWScomo 1,063,536e
DBCC SHOW_STATISTICS ('IRItemAnswer_Info', 'AnswerSourceID')para AnswerSourceID=1607tem EQ_ROWScomo970,079
O banco de dados está executando o nível de compatibilidade 140 (SQL Server 2017). Executamos 2019, mas há problemas que precisamos corrigir nos procedimentos armazenados antes de podermos fazer isso.
Qual deve ser a próxima coisa que eu olho?
Escolhi a saída com pior desempenho, que são os valores mais comuns. IRItemAnswer_Infoé uma tabela contendo respostas definidas pelo usuário para associar a um evento, onde DGItemID=1949é uma das perguntas mais comuns (quase todo evento tem uma) e onde AnswerSourceID=1607é a resposta mais comum. Dado que existe uma forte correlação entre eles, como devo reordenar a consulta?
Como é um ponto de um pouco de confusão, existem dois INNER JOINs para a mesma tabela, IRItemAnswer_Info. Uma é a resposta que estou procurando (conforme identificado pela pergunta e seus links de iria.DGItemID=1879saída para ), e a segunda é um fator limitante. Eu só quero registros onde a pergunta tenha como resposta .iria.AnswerSourceIDirai.AltLabeliiai1.DGItemID=1949iiai1.AnswerSourceID=1607
Eu removi explicitamente o plano do cache (usando DBCC FREEPROCCACHE) e o executei novamente, sem alteração no resultado - o Hash Match ainda está derramando.