Inquiridor
Query lenta...

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 = 522392A 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!
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.
-
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!
-
-
-
-
-
-
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,
-
-
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!
-