Índice
Quando fazemos múltiplos consultas Em um sistema complexo, muitas vezes não tomamos o caminho adequado para ter um desempenho ideal no nível do banco de dados, com o atual avanço tecnológico e o poder de computação que muitas vezes vemos em nossos servidores, podemos pensar que a otimização de banco de dados é uma questão do passado.Isso não poderia estar mais longe da verdade, apesar do avanço na potência dos equipamentos, os bancos de dados são fundamentais para o desempenho das aplicações, por isso uma consulta bem escrita e altamente otimizada pode significar vários segundos de carga que economiza em o sistema, se multiplicarmos pelo número de usuários simultâneos, veremos como o custo e a energia estão sendo desperdiçados.
Otimize as consultas
A melhor forma de melhorar o desempenho de nossos bancos de dados é começar com consultas bem escritas, muitas vezes achamos que as consultas não são bem escritas por não estarem tão otimizadas como deveriam ser, existem várias causas para isso, uma delas é a reutilização sem reconhecimento de código; Com isso, queremos dizer que se em algum ponto fizermos uma consulta que funcione para nós com um Associação à esquerda Continuaremos a aplicá-lo ao aumentar o número de tabelas a serem consultadas, ao modificá-lo e alterar algumas cláusulas por junção interna Isso poderia encurtar o caminho e economizar o consumo do processador.
SQL é uma linguagem que embora seja bastante fácil de ler, tem muitos aspectos e muitas variações que nos permitem fazer algo que funcione da melhor e pior maneira, cabe-nos saber identificar se a nossa solução pertence a uma categoria ou outra.
Para saber que estamos no caminho certo uma das coisas mais importantes é estarmos atualizados, ou seja, não podemos continuar codificando em SQL dentro PostgreSQL como se fosse a primeira versão quando estamos no versão 9.
Sobre o uso de subconsultas
Esse é um dos erros mais comuns que cometemos, e é que pensamos em uma consulta como um conjunto de peças que combinamos até obter um resultado final, porém esse comportamento tem um alto impacto no desempenho de nosso banco de dados.
Vejamos um exemplo desse comportamento típico:
SELECT tract_id, (SELECT COUNT (*) FROM census.facts As F WHERE F.tract_id = T.tract_id) As num_facts, (SELECT COUNT (*) FROM census.lu_fact_types As Y WHERE Y.fact_type_id IN (SELECT fact_type_id FROM census. fatos F WHERE F.tract_id = T.tract_id)) As num_fact_types FROM census.lu_tracts As T;
Agora, se virmos o gráfico do EXPLIQUE A partir desta consulta, perceberemos o quão caro é fazê-lo desta forma:
PROLONGAR
SELECT T.tract_id, COUNT (f.fact_type_id) As num_facts, COUNT (DISTINCT fact_type_id) As num_fact_types FROM census.lu_tracts As T LEFT JOIN census.facts As F ON T.tract_id = F.tract_id GROUP BY T.tract_id;
Nesta nova versão de nossa consulta, evitamos usar subconsultas, em vez disso, fazemos um equivalente com Associação à esquerda Y agrupar porSe virmos o gráfico, podemos ver a diferença.
PROLONGAR
