इनर जॉइन या लेफ्ट जॉइन में बाईं ओर एक टेबल के मामले में, कई मामलों में, ऑप्टिमाइज़र यह पाएगा कि किसी भी प्रकार के भौतिक जुड़ाव को वास्तव में करने से पहले किसी भी फ़िल्टरिंग को पहले (उच्चतम चयनात्मकता) करना बेहतर है - तो वहाँ स्पष्ट रूप से संचालन के भौतिक क्रम हैं जो बेहतर हैं।
कुछ हद तक आप कभी-कभी इसे अपने SQL के साथ नियंत्रित कर सकते हैं (या इसमें हस्तक्षेप कर सकते हैं), उदाहरण के लिए, उपश्रेणियों में समुच्चय के साथ।
क्वेरी में बाधाओं को संसाधित करने का तार्किक क्रम केवल ज्ञात अपरिवर्तनीय परिवर्तनों के अनुसार ही रूपांतरित किया जा सकता है।
तो:
SELECT *
FROM a
INNER JOIN b
ON a.id = b.id
WHERE a.something = something
AND b.something = something
तार्किक रूप से अभी भी बराबर है:
SELECT *
FROM a
INNER JOIN b
ON a.id = b.id
AND a.something = something
AND b.something = something
और उनके पास आम तौर पर एक ही निष्पादन योजना होगी।
दूसरी ओर:
SELECT *
FROM a
LEFT JOIN b
ON a.id = b.id
WHERE a.something = something
AND b.something = something
इसके बराबर नहीं है:
SELECT *
FROM a
LEFT JOIN b
ON a.id = b.id
AND a.something = something
AND b.something = something
और इसलिए अनुकूलक उन्हें एक ही निष्पादन योजना में बदलने वाला नहीं है।
ऑप्टिमाइज़र बहुत ही स्मार्ट है और चीजों को काफी सफलतापूर्वक इधर-उधर करने में सक्षम है, जिसमें संक्षिप्त दृश्य और इनलाइन टेबल-वैल्यू फ़ंक्शंस के साथ-साथ कुछ विशेष प्रकार के एग्रीगेट्स के माध्यम से चीजों को काफी सफलतापूर्वक नीचे धकेलना शामिल है।
आमतौर पर, जब आप SQL लिखते हैं, तो इसे समझने योग्य, बनाए रखने योग्य और सही होना चाहिए। जहां तक निष्पादन में दक्षता की बात है, यदि ऑप्टिमाइज़र को घोषणात्मक SQL को स्वीकार्य प्रदर्शन के साथ एक निष्पादन योजना में बदलने में कठिनाई हो रही है, तो कोड को कभी-कभी सरलीकृत किया जा सकता है या उपयुक्त अनुक्रमणिका या संकेत जोड़े या उन चरणों में विभाजित किया जा सकता है जो चाहिए अधिक तेज़ी से प्रदर्शन करें - सभी आक्रमण के क्रम में।
