Eu tenho uma consulta do seguinte formulário
exec sp_executesql N' UPDATE table SET column1 = 1, modify_date=N''2020-02-12 04:55:59.000'' WHERE (column5=@P1 AND column6=@P2 )',N'@P1 nvarchar(36),@P2 int',N'458986156148',87
Eu não posso mudar nada sobre esta consulta em si. Ele vem de um aplicativo.
Toda vez que ele é executado, os valores de atualização mudam, fazendo com que um novo plano de consulta seja gerado em vez de o plano anterior ser reutilizado.
A parametrização forçada está ativada, mas não parece ter efeito sobre essa consulta, provavelmente pela forma como ela é executada.
Ao executar a própria consulta vejo um total de 4 leituras para a atualização. Nesse caso, a execução em si não causou uma atualização, pois não há linhas retornadas para a cláusula where.
Usando o criador de perfil, vejo que o tempo entre a entrada e o início da consulta é quase todo o tempo da consulta (1 segundo). A execução real é quase imediata.
O perfilador mostra 455.000 leituras!! que não são mostrados na própria execução da consulta.
Então agora eu estou me perguntando
- Posso forçar a consulta a usar o mesmo plano aqui? Um guia de plano parece utilizável apenas para a mesma consulta ou para uma consulta afetada pela parametrização forçada.
- Podemos aumentar a velocidade de compilação desta consulta? De onde vêm as 455.000 leituras? Existem muitas estatísticas nessa tabela (+- 100), mas 455.000 leituras parecem um tanto excessivas.
Isso está no SQL Server 2019, ainda sem atualizações cumulativas. Eu escaneei o changelog CU para qualquer coisa que possa ter a ver com isso.
edit/ Investigações posteriores mostraram que existem muitos bloqueios em outras tabelas durante o tempo de compilação. Tenho 300 tabelas com chave estrangeira referenciando a chave primária na minha tabela onde quero inserir.
Todos os relacionamentos de chave estrangeira são confiáveis. Haveria alguma maneira de evitar essas verificações durante a fase de compilação?
edit 2/ As dependências não são restrições de chave estrangeira, mas visualizações na tabela. Todas as visualizações que usam essa tabela têm o bloqueio SCH-S durante a execução, o que é esperado. Não está claro se isso também está causando as leituras ...
edit 3/ Aparentemente as 455.000 leituras são feitas varrendo a tabela do sistema sys.sysmultiobjrefs mais de um milhão de vezes. Isso não parece um comportamento adequado.