🔮 ♻️ 〰️ SQL गाइड: प्रश्न कैसे लिखें बेहतर (भाग 2) 🎏 🧚🏾 👁‍🗨

जारी लेख एसक्यूएल गाइड: प्रश्न कैसे लिखें बेहतर (भाग 1)

अनुरोध से निष्पादन योजनाओं तक

यह जानते हुए कि एंटीपर्टर्न स्थिर नहीं होते हैं और आप एक एसक्यूएल डेवलपर के रूप में विकसित होते हैं, और यह तथ्य कि विकल्प के बारे में सोचते समय कई बातों को ध्यान में रखना है, इसका मतलब यह है कि एंटीपैटर्न और पुनर्लेखन प्रश्नों से बचना काफी मुश्किल हो सकता है कार्य। कोई भी मदद काम में आ सकती है, यही वजह है कि कुछ उपकरणों का उपयोग करके क्वेरी ऑप्टिमाइज़ेशन के लिए अधिक संरचित दृष्टिकोण सबसे प्रभावी हो सकता है।

यह भी ध्यान दिया जाना चाहिए कि अंतिम खंड में वर्णित कुछ एंटीपैटर्न प्रदर्शन के मुद्दों में निहित हैं, जैसे कि AND , OR और NOT ऑपरेटरों और अनुक्रमणिकाओं का उपयोग करते समय उनकी अनुपस्थिति। प्रदर्शन के बारे में सोचने के लिए न केवल अधिक संरचित होना चाहिए, बल्कि एक गहन दृष्टिकोण भी होना चाहिए।

हालांकि, यह संरचित और गहराई से दृष्टिकोण मुख्य रूप से क्वेरी योजना पर आधारित होगा, जिसे आप याद करते हैं, एक क्वेरी का परिणाम है जिसे पहले "पार्सिंग ट्री" या "पार्स ट्री" में पार्स किया गया था और यह निर्धारित करता है कि कौन सा एल्गोरिदम प्रत्येक ऑपरेशन के लिए उपयोग किया जाता है और उनके निष्पादन को कैसे समन्वित किया जाता है।

क्वेरी अनुकूलन

जैसा कि आप परिचय में पढ़ते हैं, आपको उन योजनाओं की जांच करने और सेट करने की आवश्यकता हो सकती है जो मैन्युअल रूप से अनुकूलक द्वारा संकलित की जाती हैं। ऐसे मामलों में, आपको अनुरोध योजना को देखकर फिर से अपने अनुरोध का विश्लेषण करना होगा।

इस योजना का उपयोग करने के लिए, आपको डेटाबेस प्रबंधन प्रणाली द्वारा प्रदान किए गए टूल का उपयोग करना होगा। निम्नलिखित उपकरण आपके निपटान में हो सकते हैं:

कुछ पैकेजों में ऐसे उपकरण होते हैं जो क्वेरी योजना के चित्रमय प्रतिनिधित्व को उत्पन्न करते हैं। निम्नलिखित उदाहरण पर विचार करें:
अन्य उपकरण क्वेरी योजना का एक पाठ्य विवरण प्रदान करेंगे। एक उदाहरण ओरेकल में EXPLAIN PLAN स्टेटमेंट है, लेकिन निर्देश का नाम उस DBMS पर निर्भर करता है, जिसके साथ आप काम कर रहे हैं। अन्य जगहों पर आप EXPLAIN (MySQL, PostgreSQL) या EXPLAIN QUERY PLAN (SQLite) पा सकते हैं।

कृपया ध्यान दें कि जब PostgreSQL के साथ काम करते हैं, तो आप EXPLAIN बीच एक अंतर कर सकते हैं, जहां आपको बस एक विवरण मिलता है जो बताता है कि योजनाकार क्वेरी को निष्पादित किए बिना कैसे निष्पादित करना चाहता है, जबकि EXPLAIN ANALYZE वास्तव में क्वेरी का EXPLAIN ANALYZE करता है और आपको विश्लेषण लौटाता है। अपेक्षित और वास्तविक अनुरोध योजनाएं। सामान्यतया, एक वास्तविक निष्पादन योजना एक योजना है जिसमें एक अनुरोध वास्तव में निष्पादित होता है, जबकि एक मूल्यांकन निष्पादन योजना यह निर्धारित करती है कि वह अनुरोध को पूरा किए बिना क्या करेगी। यद्यपि यह तार्किक रूप से समतुल्य है, वास्तविक निष्पादन योजना बहुत अधिक उपयोगी है क्योंकि इसमें अतिरिक्त जानकारी और आँकड़े शामिल हैं जो वास्तव में तब हुआ जब अनुरोध निष्पादित किया गया था।

इस अनुभाग के बाकी हिस्सों में, आप EXPLAIN और ANALYZE बारे में अधिक जानेंगे, साथ ही साथ क्वेरी योजना और इसके संभावित प्रदर्शन के बारे में अधिक जानकारी प्राप्त करने के लिए उनका उपयोग कैसे करें। ऐसा करने के लिए, कुछ उदाहरणों के साथ शुरू करें जिसमें आप दो तालिकाओं के साथ काम करेंगे: one_million और half_million ।

आप one_million का उपयोग करके one_million तालिका से वर्तमान जानकारी प्राप्त कर सकते हैं; अनुरोध के ऊपर इसे सीधे रखना सुनिश्चित करें, और इसे निष्पादित करने के बाद, यह आपके लिए क्वेरी योजना लौटा देगा:

 EXPLAIN SELECT * FROM one_million; QUERY PLAN ____________________________________________________ Seq Scan on one_million (cost=0.00..18584.82 rows=1025082 width=36) (1 row)

इस मामले में, आप देखते हैं कि अनुरोध की लागत 0.00..18584.82 , और पंक्तियों की संख्या 1025082 । स्तंभों की संख्या की चौड़ाई 36 ।

इसके अलावा, आप ANALYZE का उपयोग करके आंकड़े अपडेट कर सकते हैं।

 ANALYZE one_million; EXPLAIN SELECT * FROM one_million; QUERY PLAN ____________________________________________________ Seq Scan on one_million (cost=0.00..18334.00 rows=1000000 width=37) (1 row)

EXPLAIN और ANALYZE अलावा, आप EXPLAIN ANALYZE साथ वास्तविक रनटाइम भी प्राप्त कर सकते हैं:

 EXPLAIN ANALYZE SELECT * FROM one_million; QUERY PLAN ___________________________________________________________ Seq Scan on one_million (cost=0.00..18334.00 rows=1000000 width=37) (actual time=0.015..1207.019 rows=1000000 loops=1) Total runtime: 2320.146 ms (2 rows)

EXPLAIN ANALYZE का उपयोग करने का नुकसान यह है कि क्वेरी वास्तव में निष्पादित होती है, इसलिए इससे सावधान रहें!

अब तक, आपके द्वारा देखे गए सभी एल्गोरिदम Seq Scan (अनुक्रमिक स्कैन) या पूर्ण तालिका स्कैन हैं: यह एक डेटाबेस में स्कैन किया गया स्कैन स्कैन तालिका की प्रत्येक पंक्ति को क्रम में पढ़ा जाता है और पाए गए कॉलम की जाँच की जाती है शर्त के अनुपालन या नहीं। प्रदर्शन के संदर्भ में, अनुक्रमिक स्कैन निश्चित रूप से सबसे अच्छा निष्पादन योजना नहीं है क्योंकि आप अभी भी एक पूर्ण तालिका स्कैन कर रहे हैं। हालांकि, यह इतना बुरा नहीं है जब तालिका स्मृति में फिट नहीं होती है: अनुक्रमिक रीड धीमी डिस्क पर भी बहुत तेज हैं।

आप इसके बारे में बाद में जानेंगे जब हम सूचकांक स्कैनिंग के बारे में बात करेंगे।

हालांकि, अन्य एल्गोरिदम हैं। उदाहरण के लिए, कनेक्शन के लिए यह क्वेरी योजना:

 EXPLAIN ANALYZE SELECT * FROM one_million JOIN half_million ON (one_million.counter=half_million.counter); QUERY PLAN _________________________________________________________________ Hash Join (cost=15417.00..68831.00 rows=500000 width=42) (actual time=1241.471..5912.553 rows=500000 loops=1) Hash Cond: (one_million.counter = half_million.counter) -> Seq Scan on one_million (cost=0.00..18334.00 rows=1000000 width=37) (actual time=0.007..1254.027 rows=1000000 loops=1) -> Hash (cost=7213.00..7213.00 rows=500000 width=5) (actual time=1241.251..1241.251 rows=500000 loops=1) Buckets: 4096 Batches: 16 Memory Usage: 770kB -> Seq Scan on half_million (cost=0.00..7213.00 rows=500000 width=5) (actual time=0.008..601.128 rows=500000 loops=1) Total runtime: 6468.337 ms

आप देखते हैं कि क्वेरी ऑप्टिमाइज़र ने यहां Hash Join चुना है! इस ऑपरेशन को याद रखें, क्योंकि आपको अपने अनुरोध की समय जटिलता का मूल्यांकन करने की आवश्यकता होगी। अभी के लिए, ध्यान दें कि half_million.counter में कोई इंडेक्स नहीं है, जिसे हम निम्नलिखित उदाहरण में जोड़ते हैं:

 CREATE INDEX ON half_million(counter); EXPLAIN ANALYZE SELECT * FROM one_million JOIN half_million ON (one_million.counter=half_million.counter); QUERY PLAN ________________________________________________________________ Merge Join (cost=4.12..37650.65 rows=500000 width=42) (actual time=0.033..3272.940 rows=500000 loops=1) Merge Cond: (one_million.counter = half_million.counter) -> Index Scan using one_million_counter_idx on one_million (cost=0.00..32129.34 rows=1000000 width=37) (actual time=0.011..694.466 rows=500001 loops=1) -> Index Scan using half_million_counter_idx on half_million (cost=0.00..14120.29 rows=500000 width=5) (actual time=0.010..683.674 rows=500000 loops=1) Total runtime: 3833.310 ms (5 rows)

आप देखते हैं कि इंडेक्स बनाकर, क्वेरी ऑप्टिमाइज़र ने Index Scan करते समय Merge join का उपयोग करने का निर्णय लिया है।

सूचकांक स्कैनिंग और पूर्ण तालिका स्कैनिंग या अनुक्रमिक स्कैनिंग के बीच अंतर पर ध्यान दें : पहला, जिसे "टेबल स्कैनिंग" भी कहा जाता है, संबंधित रिकॉर्ड को खोजने के लिए सूचकांक के डेटा या पृष्ठों को स्कैन करता है, जबकि दूसरा तालिका की प्रत्येक पंक्ति को स्कैन करता है।

आप देखते हैं कि समग्र रनटाइम कम हो गया है और प्रदर्शन बेहतर होना चाहिए, लेकिन दो इंडेक्स स्कैन हैं, जो यहां मेमोरी को अधिक महत्वपूर्ण बनाता है, खासकर यदि तालिका इसमें फिट नहीं होती है। ऐसे मामलों में, आपको पहले एक पूर्ण सूचकांक स्कैन करना चाहिए, जो तेजी से अनुक्रमिक रीड का उपयोग करके किया जाता है और कोई समस्या नहीं है, लेकिन फिर आपके पास सूचकांक मूल्य द्वारा पंक्तियों का चयन करने के लिए कई यादृच्छिक रीड ऑपरेशन हैं। ये यादृच्छिक रीड ऑपरेशन हैं जो आमतौर पर अनुक्रमिक वाले की तुलना में परिमाण के कई आदेश हैं। इन मामलों में, एक पूर्ण तालिका स्कैन वास्तव में एक पूर्ण सूचकांक स्कैन की तुलना में तेजी से होता है।

युक्ति: यदि आप EXPLAIN के बारे में अधिक जानकारी प्राप्त करना चाहते हैं या उदाहरणों पर अधिक विस्तार से विचार करना चाहते हैं, तो Guillaume Lelarge की अंडरस्टैंडिंग व्याख्या को पढ़ें।

टाइम कॉम्प्लेक्सिटी और बिग ओ

अब जब आपने क्वेरी योजना की संक्षिप्त समीक्षा कर ली है, तो आप गहराई से खुदाई शुरू कर सकते हैं और कम्प्यूटेशनल जटिलता के सिद्धांत का उपयोग करके अधिक औपचारिक शब्दों में प्रदर्शन के बारे में सोच सकते हैं। यह सैद्धांतिक कंप्यूटर विज्ञान का एक क्षेत्र है, जो अन्य बातों के अलावा, उनकी जटिलता के आधार पर कम्प्यूटेशनल समस्याओं के वर्गीकरण पर ध्यान केंद्रित करता है; ये कम्प्यूटेशनल समस्याएं एल्गोरिदम हो सकती हैं, लेकिन प्रश्न भी।

हालांकि, प्रश्नों के लिए, उन्हें आवश्यक रूप से उनकी जटिलता के अनुसार वर्गीकृत नहीं किया जाता है, बल्कि उन्हें पूरा करने और परिणाम प्राप्त करने के लिए आवश्यक समय पर निर्भर करता है। इसे समय जटिलता कहा जाता है, और आप इस प्रकार की जटिलता को तैयार करने या मापने के लिए बड़े ओ नोटेशन का उपयोग कर सकते हैं।

पदनाम बड़े O के साथ, आप रनटाइम को इनपुट के सापेक्ष कितनी तेजी से बढ़ता है, के रूप में व्यक्त करते हैं, क्योंकि इनपुट मनमाने ढंग से बड़ा हो जाता है। बड़े ओ नोटेशन गुणांक और एक निचले क्रम के सदस्यों को बाहर करता है, इसलिए आप अपनी क्वेरी के निष्पादन समय के महत्वपूर्ण हिस्से पर ध्यान केंद्रित कर सकते हैं: इसकी वृद्धि दर। जब इस तरह से व्यक्त किया जाता है, तो गुणांक और एक निचले क्रम की शर्तों को त्यागते हुए, वे कहते हैं कि समय की जटिलता को विषम रूप से वर्णित किया गया है। इसका मतलब है कि इनपुट का आकार अनंत तक जाता है।

एक डेटाबेस भाषा में, जटिलता निर्धारित करती है कि डेटा तालिकाओं के आकार के रूप में एक क्वेरी को पूरा करने में कितना समय लगता है और इसलिए डेटाबेस बढ़ता है।

कृपया ध्यान दें कि आपके डेटाबेस का आकार न केवल तालिकाओं में डेटा की मात्रा में वृद्धि से बढ़ता है, बल्कि तथ्य यह है कि इंडेक्स भी आकार में एक भूमिका निभाते हैं।

अपनी क्वेरी योजना की समय जटिलता का अनुमान लगाना

जैसा कि आपने पहले देखा था, निष्पादन योजना, अन्य बातों के अलावा, यह निर्धारित करती है कि प्रत्येक ऑपरेशन के लिए कौन सा एल्गोरिदम उपयोग किया जाता है, जो आपको क्वेरी योजना में शामिल तालिका के आकार के एक फ़ंक्शन के रूप में प्रत्येक क्वेरी निष्पादन समय को तार्किक रूप से व्यक्त करने की अनुमति देता है, जिसे जटिलता फ़ंक्शन कहा जाता है। दूसरे शब्दों में, आप क्वेरी जटिलता और प्रदर्शन का मूल्यांकन करने के लिए बड़े ओ नोटेशन और निष्पादन योजना का उपयोग कर सकते हैं।

निम्नलिखित अनुभागों में, आपको चार प्रकार की समय जटिलता का अवलोकन मिलेगा, और आप कुछ उदाहरण देखेंगे कि प्रश्नों की समय जटिलता उस संदर्भ के आधार पर भिन्न हो सकती है जिसमें इसे निष्पादित किया जाता है।

संकेत: अनुक्रमित इस कहानी का हिस्सा हैं!

हालांकि, यह ध्यान दिया जाना चाहिए कि विभिन्न प्रकार के सूचकांक, विभिन्न निष्पादन योजनाएं और विभिन्न डेटाबेस के लिए अलग-अलग कार्यान्वयन हैं, इसलिए नीचे सूचीबद्ध अस्थायी कठिनाइयां बहुत सामान्य हैं और विशिष्ट सेटिंग्स के आधार पर भिन्न हो सकती हैं।

O (1): लगातार समय

वे कहते हैं कि एक एल्गोरिथ्म निरंतर समय में काम करता है अगर उसे इनपुट डेटा के आकार की परवाह किए बिना उसी समय की आवश्यकता होती है। जब किसी क्वेरी की बात आती है, तो इसे निरंतर समय में निष्पादित किया जाएगा यदि तालिका के आकार की परवाह किए बिना उसी समय की आवश्यकता होती है।

इस प्रकार की क्वेरी वास्तव में सामान्य नहीं है, लेकिन यहां एक ऐसा उदाहरण है:

 SELECT TOP 1 t.* FROM t

समय जटिलता निरंतर है, क्योंकि तालिका से एक मनमानी पंक्ति का चयन किया जाता है। इसलिए, समय की लंबाई तालिका के आकार पर निर्भर नहीं होनी चाहिए।

रैखिक समय: ओ (एन)

वे कहते हैं कि एल्गोरिथ्म रैखिक समय में काम करता है, अगर इसका निष्पादन समय इनपुट डेटा के आकार के सीधे आनुपातिक है, अर्थात, इनपुट डेटा के आकार के साथ समय रैखिक रूप से बढ़ता है। डेटाबेस के लिए, इसका मतलब है कि निष्पादन का समय तालिका के आकार के सीधे आनुपातिक होगा: जैसा कि तालिका में पंक्तियों की संख्या बढ़ती है, क्वेरी निष्पादन समय बढ़ता है।

एक उदाहरण एक अनिर्दिष्ट कॉलम के लिए WHERE साथ एक क्वेरी है: एक पूर्ण तालिका स्कैन या Seq Scan की आवश्यकता होगी, जो O (n) समय की जटिलता को जन्म देगा। इसका मतलब है कि वांछित पहचानकर्ता (आईडी) के साथ लाइन खोजने के लिए प्रत्येक पंक्ति को पढ़ा जाना चाहिए। आपके पास कोई प्रतिबंध नहीं है, इसलिए आपको प्रत्येक पंक्ति की गणना करने की आवश्यकता है, भले ही पहली पंक्ति स्थिति से मेल खाती हो।

निम्नलिखित क्वेरी उदाहरण पर भी विचार करें, जिसमें i_id फ़ील्ड पर कोई इंडेक्स नहीं होने पर O (n) जटिलता होगी:

 SELECT i_id FROM item;

पूर्ववर्ती का अर्थ यह भी है कि अन्य प्रश्न, जैसे कि प्रश्नों की संख्या की गणना करने के लिए COUNT (*) FROM TABLE; ओ (एन) समय जटिलता होगी, क्योंकि एक पूर्ण तालिका स्कैन की आवश्यकता होगी क्योंकि तालिका के लिए कुल पंक्तियों को सहेजा नहीं गया है। अन्यथा, समय जटिलता O (1) के समान होगी।

रेखीय रनटाइम उन योजनाओं के रनटाइम से निकटता से संबंधित है जिनमें टेबल जॉइन होती है। यहाँ कुछ उदाहरण हैं:

हैश ज्वाइन में O (M + N) की अपेक्षित जटिलता है। क्लासिक हैश आंतरिक रूप से दो तालिकाओं में शामिल होने के लिए एल्गोरिथ्म में शामिल होता है, पहले छोटी मेज की हैश तालिका तैयार करता है। हैश टेबल प्रविष्टियों में एक कनेक्शन विशेषता और इसकी स्ट्रिंग होती है। हैश फ़ंक्शन कनेक्शन विशेषता पर हैश फ़ंक्शन को लागू करके हैश तालिका तक पहुँचा जाता है। एक बार हैश तालिका के निर्माण के बाद, एक बड़ी तालिका को स्कैन किया जाता है, और छोटी तालिका से संबंधित पंक्तियों को हैश तालिका खोजकर पाया जाता है।
मर्ज जॉइन में आमतौर पर O (M + N) जटिलता होती है, लेकिन यह जॉइन कॉलम इंडेक्स पर बहुत अधिक निर्भर करेगा और, अगर कोई इंडेक्स नहीं है, तो क्या पंक्तियों को जॉइन में इस्तेमाल की गई के अनुसार सॉर्ट किया गया है:
- यदि दोनों तालिकाएँ जुड़ने में उपयोग की गई कुंजियों के अनुसार क्रमबद्ध हैं, तो क्वेरी में O (M + N) की समय जटिलता होगी।
- यदि दोनों तालिकाओं में शामिल स्तंभों के लिए एक सूचकांक है, तो सूचकांक पहले से ही इन स्तंभों का क्रम में समर्थन करता है और छंटाई की आवश्यकता नहीं है। कठिनाई O (M + N) होगी।
- यदि कनेक्ट किए गए स्तंभों में से किसी भी तालिका में कोई अनुक्रमणिका नहीं है, तो आपको पहले दोनों तालिकाओं को क्रमबद्ध करना होगा, ताकि जटिलता O (M लॉग M + N लॉग N) जैसी दिखे।
- यदि टेबल में से केवल एक में कनेक्टेड कॉलम पर एक इंडेक्स है, तो केवल टेबल जिसमें इंडेक्स नहीं है, को ज्वाइन करने से पहले सॉर्ट करना होगा, ताकि जटिलता ओ (एम + एन लॉग एन) जैसी दिखे।
नेस्टेड जॉइन के लिए, जटिलता आमतौर पर ओ (एमएन) है। यह जुड़ाव तब प्रभावी होता है जब एक या दोनों तालिकाएँ बहुत छोटी होती हैं (उदाहरण के लिए, 10 से कम रिकॉर्ड), जो कि प्रश्नों का मूल्यांकन करते समय बहुत ही सामान्य स्थिति होती है, क्योंकि कुछ उपश्रेणियाँ केवल एक पंक्ति को लौटाने के लिए लिखी जाती हैं।

याद रखें: एक नेस्टेड जॉइन एक ऐसा जुड़ाव है जो प्रत्येक रिकॉर्ड की एक तालिका में दूसरे में प्रत्येक रिकॉर्ड के साथ तुलना करता है।

लघुगणक समय: हे (लॉग (एन))

ऐसा कहा जाता है कि एक एल्गोरिथ्म लॉगरिदमिक समय में काम करता है यदि इसका निष्पादन समय इनपुट आकार के लॉगरिदम के समानुपाती होता है; प्रश्नों के लिए, इसका मतलब है कि यदि निष्पादन समय डेटाबेस आकार के लघुगणक के लिए आनुपातिक है, तो उन्हें निष्पादित किया जाएगा।

यह लॉगरिदमिक समय जटिलता क्वेरी योजनाओं के लिए मान्य है जहां एक Index Scan या एक संकुल सूचकांक स्कैन किया जाता है। एक संकुल सूचकांक एक सूचकांक है जहां अंतिम सूचकांक स्तर में तालिका की वास्तविक पंक्तियाँ होती हैं। एक संकुल सूचकांक किसी भी अन्य सूचकांक के समान है: इसे एक या अधिक स्तंभों में परिभाषित किया गया है। वे एक सूचकांक कुंजी बनाते हैं। क्लस्टरिंग कुंजी क्लस्टर इंडेक्स का प्रमुख कॉलम है। क्लस्टर किए गए इंडेक्स को स्कैन करना मूल रूप से एक क्लस्टर इंडेक्स में ऊपर से नीचे तक की पंक्तियों या पंक्तियों के लिए आपके डीबीएमएस को पढ़ने का ऑपरेशन है।

निम्नलिखित क्वेरी उदाहरण पर विचार करें, जहां i_id लिए एक सूचकांक है और जिसके परिणामस्वरूप आमतौर पर O (लॉग (n)) जटिलता होती है:

 SELECT i_stock FROM item WHERE i_id = N;

ध्यान दें कि सूचकांक के बिना, समय जटिलता O (n) होगी।

द्विघात समय: O (n ^ 2)

यह माना जाता है कि एल्गोरिथ्म को द्विघात समय में निष्पादित किया जाता है, यदि इसका निष्पादन समय इनपुट आकार के वर्ग के लिए आनुपातिक है। फिर से, डेटाबेस के लिए, इसका मतलब है कि क्वेरी निष्पादन समय डेटाबेस आकार के वर्ग के लिए आनुपातिक है।

द्विघात समय जटिलता क्वेरी का एक संभावित उदाहरण निम्नलिखित है:

 SELECT * FROM item, author WHERE item.i_a_id=author.a_id

न्यूनतम जटिलता ओ (एन लॉग (एन)) हो सकती है, लेकिन कनेक्शन विशेषताओं की सूचकांक जानकारी के आधार पर अधिकतम जटिलता ओ (एन ^ 2) हो सकती है।

संक्षेप में, आप उनके समय की जटिलता और उनकी प्रभावशीलता के आधार पर क्वेरी प्रदर्शन के मूल्यांकन के लिए निम्नलिखित धोखा पत्र पर एक नज़र डाल सकते हैं:

एसक्यूएल ट्यूनिंग

क्वेरी निष्पादन योजना और समय की जटिलता को देखते हुए, आप अपनी SQL क्वेरी को और कस्टमाइज़ कर सकते हैं। आप निम्नलिखित बिंदुओं पर ध्यान केंद्रित करके शुरू कर सकते हैं:

सूचकांक स्कैन के साथ अनावश्यक पूर्ण तालिका स्कैन बदलें;
सुनिश्चित करें कि इष्टतम जुड़ने का आदेश लागू है।
यह सुनिश्चित करें कि अनुक्रमित का उपयोग आशातीत रूप से किया जाता है। और
छोटे तालिकाओं के पूर्ण-पाठ स्कैन (कैश छोटी तालिका पूर्ण तालिका स्कैन) का उपयोग किया जाता है।

SQL का आगे उपयोग

बधाई! आप इस लेख के अंत में आए हैं, जिसने आपको SQL प्रश्नों के प्रदर्शन पर एक छोटा सा विवरण दिया। मुझे आशा है कि आपके पास एंटीपार्टर्न, क्वेरी ऑप्टिमाइज़र और आपके क्वेरी प्लान की जटिलता का विश्लेषण, मूल्यांकन और व्याख्या करने के लिए उपयोग किए जा सकने वाले टूल के बारे में अधिक जानकारी होगी। हालाँकि, आपको अभी भी बहुत कुछ पता है! यदि आप अधिक जानना चाहते हैं, तो आर। रामकृष्णन और जे। गेहरके की पुस्तक "डेटाबेस मैनेजमेंट सिस्टम" पढ़ें।

अंत में, मैं इस उद्धरण में आपसे StackOverflow से इनकार नहीं करना चाहता:

मेरा पसंदीदा एंटीपैटर आपके अनुरोधों की जाँच नहीं करता है।

हालाँकि, यह तब लागू होता है:

आपकी क्वेरी एक से अधिक तालिका प्रदान करती है।
आपको लगता है कि आपके पास अनुरोध के लिए इष्टतम डिज़ाइन है, लेकिन अपनी मान्यताओं को सत्यापित करने का प्रयास न करें।
आप पहले कार्य अनुरोध को स्वीकार करते हैं, यह नहीं जानते कि यह इष्टतम के कितना करीब है।

SQL गाइड: प्रश्न कैसे लिखें बेहतर (भाग 2)