धीमी क्वेरी पहचानना और ठीक करना
‘यह क्वेरी धीमी है, इसे ठीक कीजिए’ जैसे इंटरव्यू प्रश्न के लिए निदान-जाँच सूची
धीमी क्वेरी पहचानना और ठीक करना, CoddyKit पर कोडिंग साक्षात्कार की तैयारी का एक निःशुल्क पाठ है। यह 4 में से 4वाँ पाठ है। आप नीचे पूरा पाठ निःशुल्क पढ़ सकते हैं—फिर अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर के साथ ब्राउज़र में इसका व्यावहारिक अभ्यास कर सकते हैं। यह कोडिंग साक्षात्कार की तैयारी सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। कोडिंग साक्षात्कार की तैयारी पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
‘यह क्वेरी धीमी है, इसे ठीक करें’ वाला प्रश्न
यह साक्षात्कार का अंतिम प्रश्न होता है: साक्षात्कारकर्ता आपको एक धीमी क्वेरी और उसका EXPLAIN ANALYZE प्लान देता है और उसका निदान करने को कहता है। वे याद की हुई तरकीबों की नहीं, बल्कि एक विधि की जाँच कर रहे होते हैं।
एक मजबूत उत्तर में जाँच-सूची को ज़ोर से दोहराएँ: मापें, प्लान पढ़ें, प्रमुख लागत खोजें, परिकल्पना बनाएँ, समाधान सुझाएँ और सत्यापित करें। यह पाठ उस जाँच-सूची को चरण-दर-चरण तैयार करता है।
व्यवस्थित रहें और अपना तर्क स्पष्ट करते जाएँ; वरिष्ठ स्तर का मूल्यांकन पाने में यही सबसे महत्वपूर्ण है।
चरण 1: EXPLAIN ANALYZE से मापें
केवल एसक्यूएल देखकर कभी अनुमान न लगाएँ। EXPLAIN (ANALYZE, BUFFERS) से वास्तविक प्लान प्राप्त करें।
ANALYZE वास्तविक समय और पंक्तियों की संख्या देता है; BUFFERS बताता है कि डेटा कैश से मिल रहा है या डिस्क से पढ़ा जा रहा है। दोनों मिलकर बताते हैं कि क्वेरी CPU-सीमित है, इनपुट/आउटपुट-सीमित है या बस बहुत अधिक काम कर रही है।
इसे दो-तीन बार चलाएँ; पहली बार कैश ठंडा होने के कारण अतिरिक्त समय लग सकता है और समय-मापन विकृत हो सकता है।
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE o.created_at >= '2026-01-01';चरण 2: प्रमुख नोड खोजें
बेतरतीब ढंग से ऊपर से नीचे तक न पढ़ें। वह नोड खोजें जहाँ वास्तव में सबसे अधिक समय लग रहा है।
प्रत्येक नोड का स्वयं का समय निकालें: उसका कुल actual time घटा दें उसके बच्चों का समय, और फिर उसे loops से गुणा करें। जिस नोड का हिस्सा सबसे बड़ा हो, वही आपका लक्ष्य है; बाकी सब गौण है।
साक्षात्कार में कहें: कुल चलने के समय का 80 प्रतिशत इसी एक अनुक्रमिक स्कैन में लग रहा है, इसलिए मेरा ध्यान यहीं है। किसी और चीज़ को अनुकूलित करना व्यर्थ प्रयास होगा।
चरण 3: अनुमानित और वास्तविक मान की तुलना करें
प्रमुख नोड पर अनुमानित पंक्तियों की संख्या की तुलना वास्तविक पंक्तियों की संख्या से करें। बड़ा अंतर बताता है कि प्लानर सही जानकारी के बिना काम कर रहा है और संभवतः गलत प्लान चुन चुका है (गलत जॉइन एल्गोरिद्म, गलत पहुँच विधि)।
उदाहरण में अनुमान वास्तविक संख्या से 1000 गुना कम है। किसी भी चीज़ का पुनःडिज़ाइन करने से पहले आँकड़े ताज़ा करें; यह एक आदेश अक्सर बिना किसी अतिरिक्त लागत के प्लान ठीक कर देता है।
ANALYZE कॉलम के आँकड़ों की फिर से गणना करता है; VACUUM ANALYZE हटाई जा चुकी पंक्तियों को भी साफ करता है और दृश्यता मानचित्र को अपडेट करता है।
-- estimate rows=100, actual rows=120000 -> stale stats
ANALYZE orders;
-- or, for bloated tables:
VACUUM ANALYZE orders;सामान्य कारण: इंडेक्स वाले कॉलम पर फ़ंक्शन
सबसे आम और ठीक की जा सकने वाली त्रुटि यह है: WHERE में कोई फ़ंक्शन या रूपांतरण कॉलम को लपेट देता है, इसलिए इंडेक्स का उपयोग नहीं हो पाता और इंजन अनुक्रमिक स्कैन करता है।
उदाहरण में हर पंक्ति पर DATE() लागू होने के कारण पूरा स्कैन करना पड़ता है। इसे बिना लपेटे कॉलम वाली परास-शर्त (इंडेक्स-अनुकूल रूप) में लिखें और created_at पर मौजूद इंडेक्स काम करने लगेगा।
WHERE lower(email)=... के लिए भी यही विचार लागू होता है: सामान्यीकृत डेटा रखें, बिना लपेटे कॉलम पर क्वेरी करें या अभिव्यक्ति इंडेक्स बनाएँ।
-- Not sargable: index unusable
WHERE DATE(created_at) = '2026-01-01'
-- Sargable: range over the bare column
WHERE created_at >= '2026-01-01'
AND created_at < '2026-01-02'सामान्य कारण: इंडेक्स का न होना
यदि प्रमुख नोड अत्यधिक चयनात्मक फ़िल्टर वाला अनुक्रमिक स्कैन है, या बिना इंडेक्स वाली आंतरिक कुंजी पर बहुत बड़े loops वाला नेस्टेड लूप है, तो समाधान आमतौर पर इंडेक्स होता है।
फ़िल्टर किए गए या जॉइन किए गए कॉलम पर इंडेक्स बनाएँ। उदाहरण में customer_id पर इंडेक्स बनाया गया है, ताकि जॉइन अनुक्रमिक स्कैन से इंडेक्स स्कैन पर जा सके और प्लानर कहीं सस्ता प्लान चुन सके।
EXPLAIN ANALYZE फिर चलाकर सत्यापित करें; यह मानकर न चलें कि इंडेक्स से लाभ हुआ ही होगा।
CREATE INDEX idx_orders_customer
ON orders (customer_id);सामान्य कारण: SELECT * और चौड़ी पंक्तियाँ
SELECT * डिस्क से और नेटवर्क के माध्यम से हर कॉलम खींचता है, और यह केवल-इंडेक्स स्कैन को रोकता है क्योंकि इंडेक्स में शायद ही कभी सभी कॉलम होते हैं।
केवल आवश्यक कॉलम चुनें। इससे पंक्ति का आकार घटता है, इनपुट/आउटपुट कम होता है और सभी आवश्यक कॉलमों को कवर करने वाला केवल-इंडेक्स स्कैन संभव हो सकता है।
जो साक्षात्कारकर्ता SELECT * को जानबूझकर रखता है, वह चाहता है कि आप इसे पहचानें। कॉलमों की सूची छोटी करना चौड़ी तालिकाओं पर अक्सर तेज़ और वास्तविक लाभ देता है।
-- Before
SELECT * FROM orders WHERE customer_id = 42;
-- After: only needed columns (may enable index-only scan)
SELECT order_id, amount FROM orders WHERE customer_id = 42;सामान्य कारण: डिस्क पर लिखना
यदि कोई Sort या Hash नोड डिस्क का उपयोग दिखाता है (Sort Method: external merge Disk: 25000kB या Batches: > 1), तो प्रक्रिया work_mem की सीमा से बाहर चली गई और डिस्क पर लिखी गई।
विकल्प हैं: सत्र के लिए work_mem बढ़ाएँ, क्रमबद्धता या हैश तक पहुँचने वाली पंक्तियों की संख्या घटाएँ (पहले फ़िल्टर करें), या ऐसा इंडेक्स जोड़ें जो क्रमबद्ध क्रम उपलब्ध कराए, ताकि क्रमबद्ध करने की आवश्यकता ही न पड़े।
यह सटीक, वरिष्ठ-स्तर का निदान है जिसे साक्षात्कारकर्ता महत्व देते हैं।
Sort (actual rows=2000000 loops=1)
Sort Key: o.amount
Sort Method: external merge Disk: 25000kBसामान्य कारण: बहुत अधिक पंक्तियाँ लाना
Rows Removed by Filter: 9500000 पर ध्यान दें। क्वेरी ने एक करोड़ पंक्तियाँ पढ़ीं और उनमें से लगभग सभी को छोड़ दिया; यह व्यर्थ काम का स्पष्ट उदाहरण है।
समाधान हैं: ऐसा इंडेक्स जोड़ें जिससे पहुँच के दौरान ही फ़िल्टर लागू हो (बाद में नहीं), शर्त को अधिक चयनात्मक बनाएँ या क्वेरी में फ़िल्टर को पहले लागू करें, ताकि ट्री में ऊपर कम पंक्तियाँ जाएँ।
सिद्धांत यह है: जितना कम काम करना पड़े उतना अच्छा; फ़िल्टर जितनी जल्दी और जितनी कम लागत में हो सके, उतनी जल्दी करें।
Seq Scan on events
Filter: (event_type = 'purchase')
Rows Removed by Filter: 9500000निदान की जाँच-सूची
साक्षात्कार में इसे दोहराएँ और आप अपना रास्ता नहीं भटकेंगे:
- मापें
EXPLAIN (ANALYZE, BUFFERS)से। - खोजें कि सबसे अधिक समय लेने वाला नोड कौन-सा है।
- तुलना करें अनुमानित और वास्तविक पंक्तियों की संख्या की; पहले पुराने आँकड़े ठीक करें।
- इंडेक्स-अनुकूलता जाँचें; फ़िल्टर किए गए कॉलमों से फ़ंक्शन हटाएँ।
- इंडेक्स बनाएँ चयनात्मक फ़िल्टर और जॉइन कुंजियों पर।
- कॉलम कम करें;
SELECT *से बचें। - ध्यान दें कि कहीं डिस्क पर लिखना या बहुत अधिक डेटा लाना तो नहीं हो रहा।
- सत्यापित करें कि प्लान फिर चलाने पर परिणाम सही है।
इसे एक साथ समझें
आइए एक पूरा उदाहरण ज़ोर से समझते हैं। योजना में 50M-पंक्ति वाली orders तालिका पर क्रमिक स्कैन, customer_id = 42 फ़िल्टर और लगभग 50M का Rows Removed by Filter दिखता है; अनुमान वास्तविक परिणाम से लगभग मेल खाता है।
निदान: फ़िल्टर चयनात्मक है, इंडेक्स नहीं है और सबसे बड़ी लागत स्कैन की है। सुधार: CREATE INDEX ON orders(customer_id)। फिर चलाने पर योजना इंडेक्स स्कैन में बदल जाती है और समय कुछ सेकंड से घटकर एक मिलीसेकंड से भी कम हो जाता है।
मापने-निदान करने-सुधारने-सत्यापित करने का यह चक्र धीमी-क्वेरी वाले किसी भी प्रश्न का उत्तर-ढाँचा है।
CREATE INDEX idx_orders_customer ON orders (customer_id);
EXPLAIN (ANALYZE, BUFFERS)
SELECT order_id, amount FROM orders WHERE customer_id = 42;त्वरित जाँच
एक क्वेरी WHERE YEAR(order_date) = 2026 से फ़िल्टर करती है और योजना में order_date पर पहले से मौजूद बी-ट्री इंडेक्स के बावजूद पूरी तालिका का क्रमिक स्कैन दिखता है। सबसे पहले कौन-सा सुधार करना उचित होगा?
पुनरावलोकन
अब आपके पास धीमी-क्वेरी वाले प्रश्नों के लिए दोहराई जा सकने वाली एक विधि है:
- हमेशा मापें—
EXPLAIN (ANALYZE, BUFFERS)का उपयोग करके—और सबसे अधिक लागत वाले नोड पर ध्यान दें। - जब अनुमान और वास्तविक परिणाम अलग हों, तो सबसे पहले पुराने आँकड़ों को ठीक करें।
- शर्तों को इंडेक्स-अनुकूल बनाएँ, चयनात्मक फ़िल्टर और जोड़-कुंजियों के लिए इंडेक्स जोड़ें, और
SELECT *का उपयोग सीमित करें। - डिस्क पर अस्थायी लेखन और आवश्यकता से अधिक डेटा लाने की समस्या दूर करें, फिर नई योजना को सत्यापित करें।
जाँच-सूची को क्रम से समझाना, ठोस बदलाव सुझाना और उसे प्रमाणित करने के लिए योजना फिर चलाना—यही वरिष्ठ स्तर का उत्तर है।
एआई शिक्षक के साथ कोडिंग साक्षात्कार की तैयारी सीखें — निःशुल्क
अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।
- पाठ्यक्रम
- 90
- पाठ
- 360
अक्सर पूछे जाने वाले प्रश्न
क्या “धीमी क्वेरी पहचानना और ठीक करना” पाठ निःशुल्क है?
हाँ—“धीमी क्वेरी पहचानना और ठीक करना” का पूरा पाठ यहाँ वेब पर निःशुल्क पढ़ा जा सकता है। इंटरैक्टिव अभ्यास (अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर) करने और कोडिंग साक्षात्कार की तैयारी पाठ्यक्रम का बाकी हिस्सा अनलॉक करने के लिए CoddyKit PRO लें। कोडिंग साक्षात्कार की तैयारी पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
“धीमी क्वेरी पहचानना और ठीक करना” में मैं क्या सीखूँगा?
‘यह क्वेरी धीमी है, इसे ठीक कीजिए’ जैसे इंटरव्यू प्रश्न के लिए निदान-जाँच सूची आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ कोडिंग साक्षात्कार की तैयारी का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।
क्या कोडिंग साक्षात्कार की तैयारी शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?
पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर कोडिंग साक्षात्कार की तैयारी शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 4वाँ पाठ है।
“धीमी क्वेरी पहचानना और ठीक करना” पाठ पूरा करने में कितना समय लगता है?
CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।
क्या मैं इस कोडिंग साक्षात्कार की तैयारी पाठ में कोड लिख और चला सकता हूँ?
हाँ। हर कोडिंग साक्षात्कार की तैयारी पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।
इस पाठ्यक्रम के सभी पाठ
- EXPLAIN प्लान पढ़ना
- Seq Scan बनाम Index Scan बनाम Index-Only
- जॉइन एल्गोरिदम: Nested Loop, Hash, Merge
- धीमी क्वेरी पहचानना और ठीक करना