Usuário com melhor resposta
Consulta SQL roda mais rapido após a primeira vez

Pergunta
-
Pessoal,
Resumo: Quando uma consulta é executada pela primeira vez, demora um monte. Nas proximas (mesma consulta com filtros diferentes), fica BEM mais rapido, quase instantaneo. Pq?
Explicação:
Tenho uma consulta no sistema (web, .net, usando ADO Net) bem "pesadinha" (relativamente, pelo volume de dados da tabela de movimentação atual. Tem que ser calculado um saldo anterior, varrendo a tabela de notas fiscais.
Ocorre o seguinte: O usuário entra na tela de Emissão de Notas. Quando ele adiciona um item, é executada esta consulta pela primeira vez, e é bastante demorado.
E no segundo item, roda a mesma consulta, mas com filtro diferente (o codProduto) , quando é adicionado, é quase instantaneo.
Pensei que a consulta fica em cache, ou algo assim (BD não é minha área), mas mesmo modificando os dados de filtro?A conexão com banco já estava no pool, é tudo no mesmo banco, o que eu não tenho certeza é se foi recentemente consultado algo nesta tabela de movimentações, antes da primeira vez que roda a consulta..
Imagino que achando uma explicação para isso, posso melhorar a performance na minha aplicação, em várias situações, algumas semelhantes com esta.
Obrigado
Respostas
-
Se o codProduto for uma chave primária, foi criado um índice na sua tabela de pesquisa. Isso aumenta o desempenho de forma significativa. Verifique se os campos de pesquisa usados como filtro devem possuir respectivos índices.
Leonardo Borges 'Xis'
"Mas a persistência é o que leva a perfeição."
Se a resposta for útil, marque-a. Poderá ser útil para outros desenvolvedores.- Marcado como Resposta Julio Costi quinta-feira, 15 de setembro de 2011 12:31
-
Olá Julio,
Isso é característica do SGBD.
Quando mandamos uma query para o banco pela primeira vez ele deve interpreta-la, acessar a base de dados, identificar o conteúdo de registros, acessar a tabela de indices e alocar conteúdo em memória.
A segunda vez é mais fácil, pois o banco de dados "já conhece o caminho" e já tem muita informação em memória.
Vc pode melhorar a performance disso de três maneira:
1 - Utilize views
2 - Utilize procedures
3 - Utilize procedures com views
Por que isso? Pois procedures e views são códigos já compilados e contidos no banco de dados.
Isso faz com que o seu SGBD atribua mais "confiança" nos comandos que estão sendo executados, e tem conhecimento do domínio dos dados que serão selecionados.
[]s!
Fernando Henrique Inocêncio Borba Ferreira
while(alive){ this.WriteCode(); }
Blog: http://ferhenriquef.wordpress.com/
Twitter: @ferhenrique- Marcado como Resposta Julio Costi quinta-feira, 15 de setembro de 2011 12:31
Todas as Respostas
-
Se o codProduto for uma chave primária, foi criado um índice na sua tabela de pesquisa. Isso aumenta o desempenho de forma significativa. Verifique se os campos de pesquisa usados como filtro devem possuir respectivos índices.
Leonardo Borges 'Xis'
"Mas a persistência é o que leva a perfeição."
Se a resposta for útil, marque-a. Poderá ser útil para outros desenvolvedores.- Marcado como Resposta Julio Costi quinta-feira, 15 de setembro de 2011 12:31
-
Olá Julio,
Isso é característica do SGBD.
Quando mandamos uma query para o banco pela primeira vez ele deve interpreta-la, acessar a base de dados, identificar o conteúdo de registros, acessar a tabela de indices e alocar conteúdo em memória.
A segunda vez é mais fácil, pois o banco de dados "já conhece o caminho" e já tem muita informação em memória.
Vc pode melhorar a performance disso de três maneira:
1 - Utilize views
2 - Utilize procedures
3 - Utilize procedures com views
Por que isso? Pois procedures e views são códigos já compilados e contidos no banco de dados.
Isso faz com que o seu SGBD atribua mais "confiança" nos comandos que estão sendo executados, e tem conhecimento do domínio dos dados que serão selecionados.
[]s!
Fernando Henrique Inocêncio Borba Ferreira
while(alive){ this.WriteCode(); }
Blog: http://ferhenriquef.wordpress.com/
Twitter: @ferhenrique- Marcado como Resposta Julio Costi quinta-feira, 15 de setembro de 2011 12:31
-
Fernando
em primeiro , valeu as dicas, é interessante mesmo pensar em modificações para restruturar o codigo, dessa forma.
Atualmente, com esta forma de pegar o saldo lendo a movimentação, é uma forma pratica, não preciso me preocupar com nada, apenas gravar os itens da nota corretamente...
Mas veja, a minha necessidade "maior". É que no momento eu estou pensando seriamente em modificar esta logica de pegar esses saldos direto pela tabela das movimentações... é uma consulta meio complicada, com várias sub-consultas, e claro, a tabela de movimentações sempre está crescendo.
Pensei em tabelas que acumulam os saldos por periodos, entre outras coisas, mas, penso tambem se isso realmente é necessário...Se o proprio BD já armazena dados das ultimas consultas em cache, e estatisticas (não sei bem de que forma), já não estaria resolvido o meu problema?
Essa particularidade que relatei, quanto a segunda vez que executa a consulta ser mais rapido, acontece com a equipe de desenvolvimento, testando o programa. Mas com o usuario, a situação pode ser diferente, por exemplo: sera que apenas a primeira vez "no dia" que o usuario adicionar um produto, vai ficar lento, e as proximas ficará "em cache", mais rapido, ou isso vai variar conforme recursos de memoria, etc etc ?
Como poderia avaliar melhor o impacto, apenas presenciando o trabalho da empresa? (oq seria bem problematico, pois são varias filiais); ou tem algum meio de mensurar/definir isso?
Julio C. -