Trong trường hợp THAM GIA BÊN TRONG hoặc một bảng ở bên trái trong THAM GIA TRÁI, trong nhiều trường hợp, trình tối ưu hóa sẽ thấy rằng tốt hơn nên thực hiện bất kỳ bộ lọc nào trước (tính chọn lọc cao nhất) trước khi thực hiện bất kỳ loại liên kết vật lý nào - vì vậy, có rõ ràng là thứ tự vật lý của các hoạt động tốt hơn.
Ở một mức độ nào đó, đôi khi bạn có thể kiểm soát điều này (hoặc can thiệp vào điều này) với SQL của bạn, chẳng hạn, với các tổng hợp trong các truy vấn con.
Thứ tự logic của việc xử lý các ràng buộc trong truy vấn chỉ có thể được chuyển đổi theo các phép biến đổi bất biến đã biết.
Vì vậy:
SELECT *
FROM a
INNER JOIN b
ON a.id = b.id
WHERE a.something = something
AND b.something = something
về mặt logic vẫn tương đương với:
SELECT *
FROM a
INNER JOIN b
ON a.id = b.id
AND a.something = something
AND b.something = something
và họ thường có cùng một kế hoạch thực hiện.
Mặt khác:
SELECT *
FROM a
LEFT JOIN b
ON a.id = b.id
WHERE a.something = something
AND b.something = something
KHÔNG tương đương với:
SELECT *
FROM a
LEFT JOIN b
ON a.id = b.id
AND a.something = something
AND b.something = something
và do đó, trình tối ưu hóa sẽ không biến chúng thành cùng một kế hoạch thực thi.
Trình tối ưu hóa rất thông minh và có thể di chuyển mọi thứ xung quanh khá thành công, bao gồm cả chế độ xem thu gọn và các chức năng có giá trị bảng nội tuyến cũng như thậm chí đẩy mọi thứ xuống thông qua một số loại tổng hợp khá thành công.
Thông thường, khi bạn viết SQL, nó cần phải dễ hiểu, có thể bảo trì và chính xác. Về hiệu quả trong quá trình thực thi, nếu trình tối ưu hóa gặp khó khăn trong việc chuyển SQL khai báo thành một kế hoạch thực thi với hiệu suất chấp nhận được, mã đôi khi có thể được đơn giản hóa hoặc các chỉ mục hoặc gợi ý thích hợp được thêm vào hoặc chia nhỏ thành các bước mà nên thực hiện nhanh chóng hơn - tất cả theo thứ tự xâm lấn liên tiếp.
