Baixo desempenho de consulta

Temos um procedimento grande (mais de 10.000 linhas) que normalmente é executado em 0,5 a 6,0 segundos, dependendo da quantidade de dados com que ele trabalha. Nos últimos meses, ele começou a levar mais de 30 segundos depois de fazermos uma atualização de estatísticas com o FULLSCAN. Quando fica lento, um sp_recompile "corrige" o problema, até que o trabalho de estatísticas noturnas seja executado novamente.

Ao comparar os planos de execução lenta e rápida, reduzi-o a uma tabela / índice específico. Quando corre devagar, estima-se que ~ 300 linhas serão retornadas de um índice específico; quando corre rápido, calcula 1 linha. Quando fica lento, ele usa um spool de tabela após fazer uma busca no índice; quando é executado rapidamente, não faz o spool de tabela.

Usando o DBSS SHOW_STATISTICS, eu representei graficamente o histograma de índice no excel. Eu normalmente esperaria que o gráfico fosse mais "colinas", mas, em vez disso, parece uma montanha, o ponto mais alto sendo 2x-3x maior que a maioria dos outros valores no gráfico.

Se eu atualizar as estatísticas, sem o FULLSCAN, parecerá mais normal. Se eu executá-lo com o FULLSCAN novamente, parece que eu descrevi acima.

Parece um problema de detecção de parâmetros e está relacionado especificamente à distribuição de índice (aparentemente) estranha acima.

O proc obtém um parâmetro com valor de tabela. O sniffing de parâmetro pode ocorrer em um parâmetro com valor de tabela?

EDIT: O proc também possui 12 outros parâmetros, alguns dos quais são opcionais, dois dos quais são uma data de início e fim.

O histograma é estranho ou estou latindo na árvore errada?

Estou certamente confortável tentando ajustar a consulta e / ou tentar ajustar minha indexação. Se essa é a correção ótima, nesse momento minha pergunta é mais sobre o histograma distorcido.

Devo mencionar que este é um índice de cluster PK IDENTITY. Temos dois sistemas que conversam entre si, um sistema legado e outro um sistema caseiro. Ambos os sistemas armazenam dados semelhantes. Para mantê-los sincronizados, o PK nesta tabela no novo sistema é incrementado quando coisas são adicionadas ao sistema antigo, mesmo que os dados não sejam recuperados (uma RESEED é feita). Portanto, pode haver algumas lacunas na numeração nesta coluna. Os registros são raramente, se alguma vez, excluídos.

Qualquer pensamento seria muito apreciado. Fico feliz em reunir / incluir mais informações.

Isso acabou relacionado ao parâmetro sniffing. Aconteceu que algumas versões estranhamente formadas dessa consulta estavam sendo executadas logo após as estatísticas terem sido reconstruídas. Portanto, o plano em cache não era representativo da maioria das chamadas. Eu usei o truque de copiar os parâmetros de data para variáveis ​​locais e isso está funcionando muito bem, com pouco ou nenhum impacto no desempenho. Isso não responde por que o histograma parece tão "desligado", mas explica meus problemas de desempenho.