Bancos de dados - otimização de consultas

Assuntos Gerais
#1

Olá…
Esses dias, analisando a estruturação de uma aplicação da qual participei do processo de desenvolvimento, surgiu uma dúvida…
Os BD’s mais amplamente utilizados fazem otimização de redundância de consultas? Algo do tipo:

SELECT Funcionários.Departamento, Supervisores.NomeSupevisor FROM Funcionários INNER JOIN Supervisores WHERE Funcionários.Departamento = Supervisores.Departamento AND Funcionários.Departamento = Supervisores.Departamento;

Percebam que utilizo a cláusula where restringindo os resultados que satisfaçam determinados critérios. Todavia, os meus 2 critérios (ligados pelos operador AND) são, na verdade, o mesmo critério duplicado. Parece uma situação estúpida, mas na aplicação que vi, esta situação pode ocorrer, pois temos um sistema que gera buscas dinâmicas, em que um usuário sem atenção pode fazer algo assim.

De qualquer forma, eu queria saber se o BD faz um pré-processamento disso para detectar esse tipo de redundância, para finalidades de otimização, ou se, neste caso, ele executa cegamente a operação definida. Se for o segundo caso, imagino que ele verifica os registros que satisfaçam o primeiro critério, depois os que satisfaçam o segundo critério e, por fim, retorne os elementos comuns entre ambos os conjuntos. Essa busca pelo crit’rio específico seria redundante…

#2

Olá,

Acredito que não seja feita qualquer otimização pelo banco, caso contrário seria necessário que ele mesmo fizesse uma análise dos conjuntos de dados gerados em cada uma das consultas, o que me parece extrapolar a sua própria função, além do overhead.

Como exemplo, temos um DBA na empresa, e volta e meia pedimos auxílio a ele para que sejam feitas otimizações em consultas mais complexas (as tabelas são MUITO grandes), posso afirmar que a diferença é, algumas vezes, espantosa.

Abs,

#3

Não teria que comparar conjuntos de dados não…Falo de um pré-processamento da instrução submetida em SQL. Uma análise semântica poderia detectar certas “coisas estúpidas” nas consultas…

#4

Então devo assumir que o BD não faz esse tipo de pré-análise?

#5

Cara, ele executa com esse ‘where’ a mais sim e consequentemente consome mais também.
O que é possível fazer é rodar um advisor em cima dessa query, ele vai indicar a redundância.
Estou falando no caso de Oracle.

#6

[quote=Jokabeludoido]Olá…
Esses dias, analisando a estruturação de uma aplicação da qual participei do processo de desenvolvimento, surgiu uma dúvida…
Os BD’s mais amplamente utilizados fazem otimização de redundância de consultas? Algo do tipo:

SELECT Funcionários.Departamento, Supervisores.NomeSupevisor FROM Funcionários INNER JOIN Supervisores WHERE Funcionários.Departamento = Supervisores.Departamento AND Funcionários.Departamento = Supervisores.Departamento;

Percebam que utilizo a cláusula where restringindo os resultados que satisfaçam determinados critérios. Todavia, os meus 2 critérios (ligados pelos operador AND) são, na verdade, o mesmo critério duplicado. Parece uma situação estúpida, mas na aplicação que vi, esta situação pode ocorrer, pois temos um sistema que gera buscas dinâmicas, em que um usuário sem atenção pode fazer algo assim.

De qualquer forma, eu queria saber se o BD faz um pré-processamento disso para detectar esse tipo de redundância, para finalidades de otimização, ou se, neste caso, ele executa cegamente a operação definida. Se for o segundo caso, imagino que ele verifica os registros que satisfaçam o primeiro critério, depois os que satisfaçam o segundo critério e, por fim, retorne os elementos comuns entre ambos os conjuntos. Essa busca pelo crit’rio específico seria redundante…[/quote]

Os otimizadores dos bancos de dados costumam fazer esse tipo de análise sim, mas algumas coisas podem atrapalhar. Se, em vez de você ter algo como:

WHERE Funcionários.Departamento = Supervisores.Departamento AND 
Funcionários.Departamento = Supervisores.Departamento

você tivesse algo como (que é uma coisa muito comum):

WHERE UPPER(Funcionários.Departamento) = UPPER(Supervisores.Departamento) AND 
UPPER(Funcionários.Departamento) = UPPER(Supervisores.Departamento)

pode ser que o otimizador veja que foi aplicada uma função sobre o argumento, e isso faz com que ele já não consiga mais otimizar a consulta, porque não sabe o comportamento da função. Por exemplo, poderíamos ter uma função que a cada vez que fosse aplicada retornasse um resultado diferente. O fato de converter uma data do banco de dados com “TO_DATE” ou coisa parecida já atrapalha a otimização.

#7

[quote=Jokabeludoido]Olá…
Esses dias, analisando a estruturação de uma aplicação da qual participei do processo de desenvolvimento, surgiu uma dúvida…
Os BD’s mais amplamente utilizados fazem otimização de redundância de consultas? Algo do tipo:

SELECT Funcionários.Departamento, Supervisores.NomeSupevisor FROM Funcionários INNER JOIN Supervisores WHERE Funcionários.Departamento = Supervisores.Departamento AND Funcionários.Departamento = Supervisores.Departamento;
[/quote]

Faz muito tempo que Joins não são feitos assim. São feitos assim:

SELECT F.Departamento, S.NomeSupevisor
FROM Funcionários F INNER JOIN Supervisores S
ON F.Departamento = S.Departamento

A instrução ON é mais eficiente que WHERE por acontecer em tempos diferentes da pesquisa
O where é apenas usado para filtrar os dados e nunca para casar as tabelas.
Com ON o compilador/processador de queries sabe o que significa , com Where ele não sabe e fará a filtragem apenas depois de pegar todos os itens de cada tabela e comparar.

É claro que cada fornecedor de SGBD tem as suas gambiarras para otimizar as consultas, mas o fato de vc escrever a consulta da formam ais correta(moderna/legivel) sempre ajudará o compilador de qualquer SGDB.

#8

Todos bancos de dados modernos possuem engines de otimização muito avançadas.
Isso é a norma a quase uma década, por sinal.

#9

[quote=louds]Todos bancos de dados modernos possuem engines de otimização muito avançadas.
Isso é a norma a quase uma década, por sinal.
[/quote]
Pois é, eu realmente achei que tivesse ouvido falar disso em Bancos de dados 2, hehehe…O problema é que fz tempo e eu já não sabia se era coisa da minha cabeça. De qaulquer forma, tinha certeza que otimizavam, mas não em relação a que…No meu caso, por exemplo, não sabia se eles eram poderosos o suficiente para identificar essas redundâncias…

Valeu pelas respostas pessoal…Foram muito esclarecedoras. Essa da cláusula ON, por exemplo, é algo novo pra mim. Passei tempo demais trabalhando com computação científica, na qual boa parte do tempo eu precisava ler arquivos estruturados em formados específicos e trabalhar com tudo em memória…

#10