Estou examinando as consultas executadas por um aplicativo de terceiros. O aplicativo foi sinalizado como lento por alguns de nossos usuários finais.
Parece INSERTgravar em um HEAP e, em seguida, DELETEnovamente após o término da sessão (sem nenhuma seleção acontecendo neles?) Mas no final de cada INSERTinstrução, há um arquivo SELECT 0.
Estou vendo algum tipo de artefato do cache do plano de consulta? É possível que esteja faltando algum parâmetro? Todos os outros parâmetros são claramente indicados como por exemplo @P1.
Existem 350 INSERTações por minuto e uma hora DELETEde tudo na tabela. O que parece ser um bom caso para usar um HEAP, no entanto, se este SELECT 0 estiver realmente selecionando algo deste heap, estou me perguntando se devo adicionar um índice clusterizado.
Atualização: Adicionada uma captura de tela para mostrar a seleção:
Um plano de execução só terá o código que foi compilado e usado pela última vez, que eu saiba. Na solução de problemas de aplicativos, eu mesmo descobri onde uma instrução que eu estava olhando por meio do plano de execução foi realmente escrita
sp_executesql, assim como o T-SQL dinâmico que continha um pouco mais de lógica do que o resultado final.Você não especifica a versão com a qual está trabalhando, mas sugiro usar um rastreamento do lado do servidor ou uma sessão de evento estendido para mapear a sequência de comandos sendo passados para que você entenda completamente o que está sendo feito em sua situação.
Meu primeiro pensamento é que o aplicativo (ou o desenvolvedor) escreveu a instrução de inserção e, de alguma forma ou modo, está verificando algo (ou seja, talvez erros). Nessa verificação, se é bom, eles estão simplesmente passando o que acaba parecendo
SELECT 0, onde, se ocorrer um problema, pode retornarSELECT 3910que significaria algo para esse aplicativo. Você só verá a lógica completa (se houver) por trás de tudo isso fazendo um rastreamento nos comandos.