Query lenta...

Question

     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!

Answer 1

   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.

Answer 2

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!

Answer 3

 

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

 

Abs;

Answer 4

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!

Answer 5

MWRamos,

 

Entre estes índices existem algum do tipo clustered?

Answer 6

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!

Answer 7

Bom dia mwramos, creio que seja extremamente importante a criação de um índice cluster.

 

 

 

 

Espero ter ajudado

Answer 8

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,

Answer 9

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.

Answer 10

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!

Answer 11

MWRamos,

 

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