none
Declarar Var na query deixa o tempo de resposta longo RRS feed

  • Pergunta

  • Tenho as seguintes situações: 

           --Update com parametro

      Declare @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


    quinta-feira, 29 de março de 2007 14:57

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.

    quinta-feira, 29 de março de 2007 19:18

Todas as Respostas

  • Bom dia Snoopy isso se deve ao fato do SQL Server gerar um plano de execução para este comando. Você pode analisar com mais detalhes pedindo no Query Analizer / Management Studio para exibir o plano de execução.

     

     

     

     

    Espero ter ajudado

    quinta-feira, 29 de março de 2007 15:05
  • 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

    quinta-feira, 29 de março de 2007 18:10
  • experimenta declarar a variavel que rebe a data como datetime.

     

    abs;

    quinta-feira, 29 de março de 2007 18:33
  • 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.

    quinta-feira, 29 de março de 2007 19:18
  • 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

    .

    quinta-feira, 29 de março de 2007 19:50
  •  

     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;

    sexta-feira, 30 de março de 2007 10:27