नहीं, उस व्यवहार पर भरोसा नहीं किया जा सकता है। ऑर्डर का निर्धारण इस बात से होता है कि क्वेरी प्लानर ने परिणाम सेट तैयार करने का निर्णय लिया है। सरल प्रश्न जैसे select * from foo_table डिस्क पर संग्रहीत क्रम में वापस आने की संभावना है, जो प्राथमिक कुंजी क्रम में हो सकता है या उनके द्वारा बनाए गए क्रम, या कुछ अन्य यादृच्छिक क्रम में हो सकता है। अधिक जटिल प्रश्न, जैसे कि select * from foo where bar < 10 इसके बजाय एक अलग कॉलम के क्रम में वापस किया जा सकता है, एक इंडेक्स रीड के आधार पर, या टेबल ऑर्डर द्वारा टेबल स्कैन के लिए। where . को बहुगुणित करने के साथ और भी अधिक विस्तृत प्रश्न शर्तें, group by खंड, union s, जिस भी क्रम में योजनाकार निर्णय लेता है वह उत्पन्न करने के लिए सबसे कुशल होगा।
यह क्रम दो समान प्रश्नों के बीच भी बदल सकता है क्योंकि डेटा उन प्रश्नों के बीच बदल गया है। एक "कहां" क्लॉज एक क्वेरी में इंडेक्स स्कैन से संतुष्ट हो सकता है, लेकिन बाद में इंसर्ट्स उस स्थिति को कम चयनात्मक बना सकता है, और प्लानर टेबल स्कैन का उपयोग करके बाद की क्वेरी को निष्पादित करने का निर्णय ले सकता है।
उस पर एक बेहतर बिंदु डालने के लिए। RDBMS सिस्टम के पास आपको बिल्कुल देने का अधिदेश है आपने जो मांगा है, यथासंभव कुशलता से। यह दक्षता कई रूप ले सकती है, जिसमें IO को छोटा करना (डिस्क पर और साथ ही आपको डेटा भेजने के लिए नेटवर्क पर), CPU को छोटा करना और इसके वर्किंग सेट के आकार को छोटा रखना (उन विधियों का उपयोग करना जिनमें न्यूनतम अस्थायी भंडारण की आवश्यकता होती है) शामिल हैं।
बिना ORDER BY . के खंड, आपने बिल्कुल नहीं पूछा होगा किसी विशेष आदेश के लिए, और इसलिए RDBMS आपको किसी क्रम में वे पंक्तियाँ देगा जो (शायद) क्वेरी के कुछ संयोगात्मक पहलू से मेल खाती हैं, जो भी एल्गोरिदम RDBMS द्वारा डेटा को सबसे तेज़ बनाने की अपेक्षा की जाती है।
यदि आप दक्षता की परवाह करते हैं, लेकिन ऑर्डर की नहीं, तो ORDER BY . को छोड़ दें खंड। यदि आप ऑर्डर की परवाह करते हैं लेकिन दक्षता की नहीं, तो ORDER BY . का उपयोग करें खंड।
चूँकि आप वास्तव में BOTH . की परवाह करते हैं ORDER BY . का उपयोग करें और फिर अपनी क्वेरी और डेटाबेस को ध्यान से ट्यून करें ताकि यह कुशल हो।
