none
Query lenta... RRS feed

  • Pergunta

  •      Estou executando a seguinte query no Sql-Server 2000, que está lenta:

     

    SELECT SUM(Nci.Quantidade) AS Saldo
           FROM sicNfItem Nci INNER JOIN sicNotaFiscal Nfc
                       ON Nci.NotaFiscal = Nfc.Chave
                              INNER JOIN sicOperacao Opc
                       ON Nfc.Operacao = Opc.Chave
          WHERE Opc.Fisico = 1
            AND Nfc.Data BETWEEN '2007/04/01' AND '2007/04/03'
            AND Nci.UnidadeNegocio = 5
            AND Nci.Produto = 522392

    A tabela sicNfItem tem:

         No Geral: 8 milhões de registros

         Apenas com o filtro da data: 30 mil registros

         Com todos os filtros: 130 registros.

     

         Os campos Nfc.Data, Nci.UnidadeNegocio e Nci.Produto são índices, mas mesmo assim no "Execution Plan" o Sql-Server está fazendo SCAN nas tabelas, alguém saberia me explicar o por quê?

         O que eu poderia fazer para que esse comando, aparentemente simples, ficasse rápido?

     

    Obrigado!

    quinta-feira, 19 de abril de 2007 22:54

Todas as Respostas

  •    Olá MWRamos olha ve se isso te ajuda:

     

       - Crie índice nonclustered nos seguintes campos:

                 - Nci.Quantidade

                 - Nci.NotaFiscal , Nfc.Chave, Nfc.Operacao = Opc.Chave

       

        - Crie índices clustered:

                 - Data, UnidadeNegocio e Produto, Opc.Fisico

     

     

       Ve se melhora tua performance.

     

        Abs.

    quinta-feira, 19 de abril de 2007 23:12
  • Rafael,

     

         Todos os campos que vc mensionou já são índices, com excessão de:

     

    Nci.Quantidade = que não é usado para pesquisa, não é necessário ser índice

    Opc.Fisico = que varia apenas entre 0 e 1, que também não é recomendado que seja, pela pouca variação de valores.

     

         Em relação a ser clustered ou nonclustered:

     

    Data, UnidadeNegocio e Produto, têm uma repetição alta de valores dentro da tabela, o que normalmente indica o uso de índice nonclustered.

     

         Passei o "Index Tuning" na minha query e ele indicou apenas a criação de um indice conjunto entre Nci.UnidadeNegocio + Nci.Produto, criei o índice mas não alterou em nada a performance, e continuou a fazer SCAN nas tabelas.

     

     

    Por favor, espero que alguém me dê uma luz, pois nesta situação estou vendo algumas teorias do Sql-Server ruírem, sempre tive boa performance com ele, mas agora seguidamente estou me deparando com este tipo de problema. E uma base contendo tabelas com 8 milhões de registros não é tão grande assim.

     

    Obrigado!

    sexta-feira, 20 de abril de 2007 13:06
  •  

     qual parte da consulta esta com table scan ?, vc. pode ter indices desnecessarios nesta consulta isso tambem resulta um table scan.

     

    Abs;

    sexta-feira, 20 de abril de 2007 13:14
  • No execution plan do query analyzer, está dando table scan nas 3 tabelas...

     

    Todos os campos envolvidos nesta consulta são índices, exceto Nci.Quantidade e Opc.Fisico.

     

    Obrigado!

    sexta-feira, 20 de abril de 2007 13:34
  • MWRamos,

     

    Entre estes índices existem algum do tipo clustered?

    sexta-feira, 20 de abril de 2007 14:03
  • Junior,

     

         Não, atualmente nenhum dos índices é clustered.

         Já fiz testes passando o Nfc.Chave para clustered, mas não houve ganho de performance.

     

    Obrigado!

    segunda-feira, 23 de abril de 2007 13:42
  • Bom dia mwramos, creio que seja extremamente importante a criação de um índice cluster.

     

     

     

     

    Espero ter ajudado

    segunda-feira, 23 de abril de 2007 14:04
  • Olá mwramos, eu não concordo com voce sobre o que diz respeito a não colocar um índice nonclustered no campo Nco.Quantidade realmente é necessário colocar um índice nonclustered para funções agregadas.

     

      Data, UnidadeNegocio e Produto são utilizadas em junções de tabela. Ou seja colunas utilizadas na junção de tabelas necessitam de índices clusterizados.

     

     

     Att,

    terça-feira, 24 de abril de 2007 02:00
  • MWRamos,

     

    Concordo com os colegas em relação a utilização de índices.

     

    Mas quem poderá definir melhor que índice utilizar é você mesmo, baseando no plano de execução que o SQL Server esta gerando para você durante a execução desta query.

    terça-feira, 24 de abril de 2007 10:11
  • Bom dia Rafael!

     

         Em relação ao índice nonclustered no campo Nci.Quantidade, por fazer parte de uma função agregada, irei fazer testes.

         Em relação a índices clustered, não que seja definitivo, mas o que a teoria diz é que eles somente devem ser utilizados em campos que tenham pouco repetição na tabela (normalmente chaves primárias, campos identity), o que não ocorre com o Nci.UnidadeNegocio, Nci.Produto e Nfc.Data, mas de qualquer forma irei testar.

         Então, levando em consideração o que você escreveu, chaves primárias e chaves estrangeiras deveriam ser índices clustered, mesmo que a chave estrangeria tenha um alto grau de repetição na tabela, pois será usada nas cláusulas de junção?

         Vou fazer os testes e postar os resultados.

     

    Obrigado!

    terça-feira, 24 de abril de 2007 13:09
  • MWRamos,

     

    não vale a pena tentar criar um indice clustered em Nfc.Data ?

     

    terça-feira, 24 de abril de 2007 14:25