Usuário com melhor resposta
Declarar Var na query deixa o tempo de resposta longo

Pergunta
-
Tenho as seguintes situações:
--Update com parametroDeclare @vFim char(10)
set @vFim = '2007/02/25'
UPDATE [SDB].[dbo].[tab]
SET Status = '1', NumRemessa = 2
WHERE (tab.Mov_CodigoCtr = '0000300' OR
tab.CodigoCtr = '0000301')AND
tab.DataMov >= @vFim AND
tab.DatyyyymmddCtrlMovBco = '20070305' AND
tab.CodigoTran = '02' AND
tab.Estorno = '0' AND
tab.NumRemessa = 0 OR NumRemessa = 2)
--Update direto
UPDATE [GSDB].[dbo].[Tab]
SET Status = '1', NumRemessa = 2
WHERE (Tab.CodigoCtr = '0000300' OR
Tab.CodigoCtr = '0000301')AND
Tab.DataMov >= '2007/02/25' AND
Tab.DatyyyymmddCtrlMovBco = '20070305' AND
Tab.CodigoTran = '02' AND
Tab.Estorno = '0' AND
(Tab.NumRemessa = 0 OR Tab.NumRemessa = 2)
O primeiro Update, na qual seto uma variável, demora mais ou menos uns 2 minutos p/ ser executada no meu banco de dados, já a segunda faz em 2 segundos.
Isto já ocorreu em algumas outras query`s que já fiz na minha base de dados. Queria saber por que, às vezes, e em alguns casos como esse ae, colocando diretamente é bem mais rápido que declarando uma variável?
obs: Esta tabela tem milhões de registros, e notei q isto ocorre com campos do tipo datetime, e já tentei declarar com outros tipos fazendo a conversão e nada!
Aguardo resposta!
[]`s
Respostas
-
Snoopy,
Como o SQL Server utiliza o plano de execução como base para realizar a melhor forma de processamento.
Em relação table scan, isso ocorre quando o plano de execução não consegui identificar a utilização de alguma coluna em seu script que possui índice. Você já criar um índice na coluna que é utilizada pelo parâmetro, ou até mesmo a variável que você esta declarando como char, declarara como datetime.
Quando o SQL Server, recebe uma valor do tipo data passado como se fosse uma string, ele internamente realização a conversão, e esta conversão faz com que o plano de execução tenha que tomar outro caminho para tentar melhorar o tempo de resposta da query.
Todas as Respostas
-
-
poxa Anderson valeu por ter respondido, mas eu sei que o plano de execução é diferente, é por isso que está a minha dúvida, eu sei que ele demora mais que o outro devido a query que tem o parâmetro faz um table scan e como minha tabela, na qual falei, tem milhões de registros, vai demorar bem mais o tempo de resposta.
Mas o que eu quero saber é por que o sql faz isto, já que a consulta praticamente é a mesma e se tem alguma solução, pois preciso colocar esta query em uma store procedure e necessito que passe parâmetro, mas devido ao tempo de resposta fica impossível.
[]`s -
-
Snoopy,
Como o SQL Server utiliza o plano de execução como base para realizar a melhor forma de processamento.
Em relação table scan, isso ocorre quando o plano de execução não consegui identificar a utilização de alguma coluna em seu script que possui índice. Você já criar um índice na coluna que é utilizada pelo parâmetro, ou até mesmo a variável que você esta declarando como char, declarara como datetime.
Quando o SQL Server, recebe uma valor do tipo data passado como se fosse uma string, ele internamente realização a conversão, e esta conversão faz com que o plano de execução tenha que tomar outro caminho para tentar melhorar o tempo de resposta da query.
-
olá junior,
Vc tava certo, eu mudei pra identificar a coluna de índice e deu certo!
É pq passando parâmetro o sql tava perdendo a coluna onde era índice, e por isso, fazia table scan, quando faço direto não preciso identificar o índice, talvez pode até ser bug do Sql Server não poder identificar o índice quando passo parâmetros, ficando assim:
Declare @vFim char(10)set @vFim = '2007/02/25'
UPDATE [SDB].[dbo].[tab] WITH [INDEX = IK_CTRDATA]
SET Status = '1', NumRemessa = 2
WHERE (tab.Mov_CodigoCtr = '0000300' OR
tab.CodigoCtr = '0000301')AND
tab.DataMov >= @vFim AND
tab.DatyyyymmddCtrlMovBco = '20070305' AND
tab.CodigoTran = '02' AND
tab.Estorno = '0' AND
tab.NumRemessa = 0 OR NumRemessa = 2)
No exemplo q postei está em char pq eu estava testando mudando o tipo da variável, mas continuava fazendo table scan, não quer dizer nada não..Valeu!
[]`s.
-
bom nao gosto de hints, acho que vc. poder em deixar o sql escolher o melhor plano de execucao, quando vc. analisou o plano de execucao achou algum table scan ?, se criar um indice especifico para essa coluna ou ate mesmo uma estatistica acho que vai mais precisar passar o hint
Abs;