Dalam kasus INNER JOIN atau tabel di sebelah kiri dalam LEFT JOIN, dalam banyak kasus, pengoptimal akan menemukan bahwa lebih baik melakukan pemfilteran apa pun terlebih dahulu (selektivitas tertinggi) sebelum benar-benar melakukan jenis gabungan fisik apa pun - jadi ada jelas merupakan urutan operasi fisik yang lebih baik.
Sampai batas tertentu Anda terkadang dapat mengontrol ini (atau mengganggu ini) dengan SQL Anda, misalnya, dengan agregat dalam subkueri.
Urutan logis pemrosesan kendala dalam kueri hanya dapat diubah sesuai dengan transformasi invarian yang diketahui.
Jadi:
SELECT *
FROM a
INNER JOIN b
ON a.id = b.id
WHERE a.something = something
AND b.something = something
masih secara logis setara dengan:
SELECT *
FROM a
INNER JOIN b
ON a.id = b.id
AND a.something = something
AND b.something = something
dan mereka umumnya akan memiliki rencana eksekusi yang sama.
Sebaliknya:
SELECT *
FROM a
LEFT JOIN b
ON a.id = b.id
WHERE a.something = something
AND b.something = something
TIDAK setara dengan:
SELECT *
FROM a
LEFT JOIN b
ON a.id = b.id
AND a.something = something
AND b.something = something
sehingga pengoptimal tidak akan mengubahnya menjadi rencana eksekusi yang sama.
Pengoptimal sangat cerdas dan mampu memindahkan berbagai hal dengan cukup sukses, termasuk menciutkan tampilan dan fungsi bernilai tabel sebaris serta bahkan mendorong berbagai hal melalui beberapa jenis agregat dengan cukup berhasil.
Biasanya, ketika Anda menulis SQL, SQL harus dapat dimengerti, dapat dipelihara, dan benar. Sejauh efisiensi dalam eksekusi, jika pengoptimal mengalami kesulitan mengubah SQL deklaratif menjadi rencana eksekusi dengan kinerja yang dapat diterima, kode terkadang dapat disederhanakan atau indeks atau petunjuk yang sesuai ditambahkan atau dipecah menjadi langkah-langkah yang harus tampil lebih cepat - semuanya dalam urutan invasif yang berurutan.
