Casos do Dia a Dia – O que a falta de paralelismo pode fazer a uma query
Olá Pessoal,
Segue mais um caso que aconteceu no meu dia a dia de trabalho.
A equipe de desenvolvimento nos passou uma query onde o resultado de um select era associado a uma variável dentro do próprio select.
ex: select @temp = @temp + (case when then end) from [vários joins] where [várias verificações]
Essa query demorava 40 segundos, mas ao executar da forma abaixo (eliminando o @temp +):
ex: select @temp = (case when then end) from [vários joins] where [várias verificações]
Ela demorava ZERO segundos.
Olhando o execution plan, foi possível verificar que a primeira query demorava pois o SQL Server não usava paralelismo, já para a segunda query, usava.
Nossa solução de contorno foi passar o resultado do select para uma outra variável e após o select somar a variável original.
ex: select @temp2 = (case when then end) from [vários joins] where [várias verificações]
set @temp = @temp + @temp2
Um dos motivos poderia ser porque o SQL Server determinou um custo mais baixo para a primeira query a ponto de não usar paralelismo de acordo com a definição do “cost threshold for parallelism“. Contudo, não consegui evidenciar isso.
Olhando numa visão mais leiga, parece ser uma operação simples somar o valor de uma variável a ela mesma e é difícil de saber porque o SQL Server tomou caminhos diferentes tornando a query tão mais lenta.
A discussão fica aberta nos comentários para quem souber dar mais detalhes do motivo desse problema.
Ambiente: Win Server 2008 R2 e SQL Server 2008 R2 com a atualização mais recente.
Gostou dessa dica?
Cadastre seu e-mail para receber novos Posts e curta minha Página no Facebook para receber Dicas de Leituras e Eventos sobre SQL Server.
Confira mais experiências do Dia a Dia de um DBA no meu Treinamento de Tarefas do Dia a Dia de um DBA.
Abraços,
Fabrício Lima
MCITP – Database Administrator
Consultor e Instrutor SQL Server
Trabalha com SQL Server desde 2006