No caso de um INNER JOIN ou uma tabela à esquerda em um LEFT JOIN, em muitos casos, o otimizador descobrirá que é melhor realizar qualquer filtragem primeiro (maior seletividade) antes de executar qualquer tipo de junção física - então não há são obviamente ordem física de operações que são melhores.
Até certo ponto, às vezes você pode controlar isso (ou interferir nisso) com seu SQL, por exemplo, com agregações em subconsultas.
A ordem lógica de processamento das restrições na consulta só pode ser transformada de acordo com as transformações invariáveis conhecidas.
Então:
SELECT *
FROM a
INNER JOIN b
ON a.id = b.id
WHERE a.something = something
AND b.something = something
ainda é logicamente equivalente a:
SELECT *
FROM a
INNER JOIN b
ON a.id = b.id
AND a.something = something
AND b.something = something
e geralmente terão o mesmo plano de execução.
Por outro lado:
SELECT *
FROM a
LEFT JOIN b
ON a.id = b.id
WHERE a.something = something
AND b.something = something
NÃO é equivalente a:
SELECT *
FROM a
LEFT JOIN b
ON a.id = b.id
AND a.something = something
AND b.something = something
e assim o otimizador não vai transformá-los no mesmo plano de execução.
O otimizador é muito inteligente e é capaz de mover as coisas com bastante sucesso, incluindo visões recolhidas e funções com valor de tabela em linha, bem como até mesmo empurrar as coisas para baixo através de certos tipos de agregações com bastante sucesso.
Normalmente, quando você escreve SQL, ele precisa ser compreensível, sustentável e correto. No que diz respeito à eficiência na execução, se o otimizador está tendo dificuldade em transformar o SQL declarativo em um plano de execução com desempenho aceitável, o código pode às vezes ser simplificado ou índices ou dicas apropriados adicionados ou divididos em etapas que devem executar mais rapidamente - tudo em ordens sucessivas de invasão.
