SELECT LENTO
SELECT
'Extent3'.'ID_PESSOA',
'Extent2'.'DT_ACORDO',
'Extent2'.'AN_ACORDO_COM_ENTRADA',
'Extent2'.'AN_SITUACAO_ACORDO',
'Extent1'.'DT_INCLUSAO',
'Extent2'.'NR_ACORDO_BANCO',
'Extent1'.'NR_PARCELA',
'Extent1'.'VL_PARCELA',
'Extent1'.'DT_VCTO',
'Extent1'.'PERC_HONO',
'Extent1'.'VL_HONORARIO',
'Extent1'.'DT_PAGTO',
'Extent1'.'VL_HONORARIO_PAGO',
'Extent2'.'NR_OPERACAO',
'Extent2'.'VLR_SALDO_DEVEDOR',
'Extent2'.'VLR_HONO',
'Extent1'.'DT_APROVACAO',
'Extent1'.'DT_EMISSAO_NF',
'Extent1'.'NR_RECIBO',
'Extent3'.'NM_PESSOA',
'Extent3'.'CPF_CNPJ',
'Extent1'.'HO_DEVIDO',
'Extent1'.'DT_PAGTO_NF',
'Extent2'.'NR_DOSSIE',
'Extent1'.'AN_OBSERVACAO',
'Extent1'.'AN_ALEGA_PAGTO',
'Extent1'.'AN_OBSERVACAO_ALEGA',
'Extent1'.'AN_USUARIO_ALTERACAO'
FROM 'tab_chave_acordo' AS 'Extent2' INNER JOIN 'tab_acordo' AS 'Extent1' ON 'Extent1'.'NR_ACORDO_BANCO' = 'Extent2'.'NR_ACORDO_BANCO' INNER JOIN 'tab_pessoa' AS 'Extent3' ON 'Extent2'.'ID_PESSOA'= 'Extent3'.'ID_PESSOA'
where DT_VCTO >= [ô]2016-01-01[ô] and DT_VCTO <= [ô]2016-10-01[ô] AND DT_PAGTO IS NOT NULL AND NR_RECIBO IS NOT NULL Estou migrando minha base para o MYSQL, devido exigencia do cliente que não quer usar o SQLSERVER EXPRESS. Este select no sqlserver leva 1 segundo, já no mysql ele leva cerca de 15 segundos. Alguma coisa nele que pode ser otimizado?
Lembrando que as tabelas:
tb_acordo : 158 mil registros
tb_pessoa 2.500 registros
tb_chave_acordo : 7;500 registros;
Não entendo a tamanha diferença da velocidade entre um banco e outro, o que poderia ser? Lembrando que os dois estão com a mesma estutura de dados e rodando na mesma máquina.
Além disso, quando você cria uma chave primária no SQL Server, automaticamente ele gera um Ãndice clusterizado baseado nela (até onde sei, é uma peculiaridade do SQL Server). Talvez a diferença esteja aÃ.
Dá uma olhada nos Ãndices, vê se tem algo no SQL Server que não tem no MySQL.
Abraços!
Citação::
Isso ocorre no script query do proprio mysql ou no seu sistema?
Ocorre direto no mysql mesmo, no sistema dá o mesmo tempo
Citação:é possÃvel que essa diferença se dê por causa da camada de otimização do SQL Server. Não sei como funciona no MySQL, porque trabalhei pouco tempo com ele...
Além disso, quando você cria uma chave primária no SQL Server, automaticamente ele gera um Ãndice clusterizado baseado nela (até onde sei, é uma peculiaridade do SQL Server). Talvez a diferença esteja aÃ.
Dá uma olhada nos Ãndices, vê se tem algo no SQL Server que não tem no MySQL.
Fiz essa pergunta já pensando no que nosso amigo DS2T disse. Se for no sistema a lentidão eu recomendaria re-criar o tambor e transferir os dados de um para o outro. Isso daria um pouco de trabalho pois teria que só mudar no nome do tambor na classe de conexão.
Citação::
é como nosso amigo disse, o metodo de otimização do SQL Server e do MySql é diferente, mas se em ambos o sistema entrega uma velocidade aceitavel (rapido), tranquilo em relação ao cliente pois não irá sofrer. Já a manutenção, recomendo fazer na maquina que está o SQL Server e depois aplicar o Update na maquina que está o MySql, já que causa essa lentidão no select na manutenção.
O problema de tudo é que se eu aumentar o perÃodo de data, a consulta chega até 10 minutos, o cliente não vai ficar esperando 10 minutos um relatório. Estou completamente perdido, testei o Postgree e nele ficou mais lento ainda.
Citação:O problema de tudo é que se eu aumentar o perÃodo de data, a consulta chega até 10 minutos, o cliente não vai ficar esperando 10 minutos um relatório. Estou completamente perdido, testei o Postgree e nele ficou mais lento ainda.
Cara, há algo de podre no reino da Dinamarca.
10 minutos pra essa quantidade de dados?!
Já tentou executar direto de uma IDE como MySQL Front, Navicat, etc? Lá demora esse absurdo de tempo também?
Faça os testes:
Rode a consulta direto de uma IDE do MySQL. Deu ruim do mesmo jeito? Vá para a próxima linha.
Verifique se não fizeram nada de errado com os Ãndices da tabela (em cada uma das tabelas)... Ãndices ajudam demais, mas se você criar errado... Vai ter umas árvores B que vão cagar suas consultas todas.
Citação::
O problema de tudo é que se eu aumentar o perÃodo de data, a consulta chega até 10 minutos, o cliente não vai ficar esperando 10 minutos um relatório. Estou completamente perdido, testei o Postgree e nele ficou mais lento ainda.
Cara, há algo de podre no reino da Dinamarca.
10 minutos pra essa quantidade de dados?!
Já tentou executar direto de uma IDE como MySQL Front, Navicat, etc? Lá demora esse absurdo de tempo também?
Faça os testes:
Rode a consulta direto de uma IDE do MySQL. Deu ruim do mesmo jeito? Vá para a próxima linha.
Verifique se não fizeram nada de errado com os Ãndices da tabela (em cada uma das tabelas)... Ãndices ajudam demais, mas se você criar errado... Vai ter umas árvores B que vão cagar suas consultas todas.
.
Cara, era os indices mesmo.... Não tava usando Foreign Key, para relacionar os campos das tabelas, dai fiz aqui e cai dratiscamente o tempo, agora tá voando as consultas. Valeu ai pessoal.