DBMS — MCQ Practice

Hindi aur English dono mein practice karo — click karo answer check karne ke liye

📚 146 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
146 questions
91
EN + हिं Medium
GB What is the SQL:1999 NATURAL JOIN and why is it considered risky in production code?
IN SQL:1999 नेचुरल जॉइन क्या है और इसे उत्पादन कोड में जोखिम भरा क्यों माना जाता है?
A
A join optimized for natural data patterns प्राकृतिक डेटा पैटर्न के लिए अनुकूलित एक जुड़ाव
B
A join that requires no database knowledge एक ऐसा जुड़ाव जिसके लिए किसी डेटाबेस ज्ञान की आवश्यकता नहीं है
C
A join that works on natural language conditions एक जुड़ाव जो प्राकृतिक भाषा स्थितियों पर काम करता है
D
Automatically joins on ALL columns with the same name in both tables using equality without requiring explicit ON clause - risky because schema changes (adding a new column with same name in both tables) silently change join semantics स्पष्ट ON क्लॉज की आवश्यकता के बिना समानता का उपयोग करते हुए दोनों तालिकाओं में समान नाम वाले सभी कॉलमों पर स्वचालित रूप से जुड़ जाता है - जोखिम भरा है क्योंकि स्कीमा बदलता है (दोनों तालिकाओं में समान नाम के साथ एक नया कॉलम जोड़ना) चुपचाप जॉइन सिमेंटिक्स को बदल देता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) NATURAL JOIN risks: (1) Implicitly joins on ALL matching column names - if you add a column with same name to both tables, the join condition silently changes. (2) Hard to understand without knowing schemas. (3) Breaks when column names change. Always prefer explicit ON or USING clauses in production.
व्याख्या (हिन्दी) स्वाभाविक जुड़ाव जोखिम: (1) सभी मेल खाने वाले कॉलम नामों पर अंतर्निहित रूप से जुड़ता है - यदि आप दोनों तालिकाओं में समान नाम वाला कॉलम जोड़ते हैं, तो जुड़ने की स्थिति चुपचाप बदल जाती है। (2) स्कीमा को जाने बिना समझना कठिन है। (3) कॉलम नाम बदलने पर टूट जाता है। उत्पादन में हमेशा स्पष्ट ON या USING क्लॉज को प्राथमिकता दें।
92
EN + हिं Medium
GB What is the probe side and build side terminology in hash join and how does the optimizer decide which table is which?
IN हैश जॉइन में जांच पक्ष और बिल्ड साइड शब्दावली क्या है और ऑप्टिमाइज़र कैसे तय करता है कि कौन सी तालिका कौन सी है?
A
The build side is the left table; probe is always the right बिल्ड साइड बाईं ओर की टेबल है; जांच हमेशा सही होती है
B
Build side is always the outer table बिल्ड साइड हमेशा बाहरी टेबल होती है
C
Build side: the SMALLER relation - loaded entirely into hash table in memory. Probe side: the LARGER relation - each row is used to probe the hash table. Optimizer assigns smaller relation as build side to minimize memory requirements निर्माण पक्ष: छोटा संबंध - पूरी तरह से मेमोरी में हैश तालिका में लोड किया गया। जांच पक्ष: बड़ा संबंध - प्रत्येक पंक्ति का उपयोग हैश तालिका की जांच के लिए किया जाता है। मेमोरी आवश्यकताओं को कम करने के लिए ऑप्टिमाइज़र बिल्ड साइड के रूप में छोटे संबंध निर्दिष्ट करता है
D
The optimizer always chooses randomly अनुकूलक हमेशा यादृच्छिक रूप से चयन करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Hash join phases: Build: iterate over smaller relation (build side), compute hash(join_key), store in hash table. Probe: iterate over larger relation (probe side), compute hash(join_key), look up in hash table for matches. Smaller table as build side fits hash table in memory, avoiding grace hash join overhead.
व्याख्या (हिन्दी) हैश जुड़ने के चरण: बिल्ड: छोटे संबंध (बिल्ड साइड) पर पुनरावृत्त करें, हैश (join_key) की गणना करें, हैश तालिका में स्टोर करें। जांच: बड़े संबंध (जांच पक्ष) पर पुनरावृत्ति करें, हैश (join_key) की गणना करें, मिलान के लिए हैश तालिका में देखें। बिल्ड साइड के रूप में छोटी टेबल मेमोरी में हैश टेबल को फिट करती है, ग्रेस हैश जॉइन ओवरहेड से बचती है।
93
EN + हिं Easy
GB What does RIGHT OUTER JOIN return and is there a preferred alternative?
IN राइट आउटर जॉइन क्या लौटाता है और क्या कोई पसंदीदा विकल्प है?
A
All rows from the right table plus non-matching left table rows दाहिनी तालिका की सभी पंक्तियाँ और बाईं तालिका की गैर-मिलान पंक्तियाँ
B
Only rows where the right table has NULL values केवल वे पंक्तियाँ जहाँ दाएँ तालिका में NULL मान हैं
C
All rows from RIGHT table (with NULLs for unmatched left side) and only matching rows from LEFT table - functionally equivalent to reversing table order and using LEFT OUTER JOIN (which is more readable and universally preferred) दाएँ तालिका से सभी पंक्तियाँ (बेजोड़ बाईं ओर के लिए NULL के साथ) और बाईं तालिका से केवल मेल खाने वाली पंक्तियाँ - कार्यात्मक रूप से तालिका क्रम को उलटने और LEFT OUTER JOIN का उपयोग करने के बराबर (जो अधिक पठनीय और सार्वभौमिक रूप से पसंदीदा है)
D
All rows from both tables दोनों तालिकाओं से सभी पंक्तियाँ
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) RIGHT JOIN (A, B) = LEFT JOIN (B, A) with reversed table order. Since LEFT JOIN is more natural (read left-to-right: I want all of the left table), most developers avoid RIGHT JOIN and simply reorder the tables to use LEFT JOIN. Results are identical; its a code readability convention.
व्याख्या (हिन्दी) दाएं जोड़ (ए, बी) = बाएं जोड़ (बी, ए) उलटे तालिका क्रम के साथ। चूंकि लेफ्ट जॉइन अधिक प्राकृतिक है (बाएं से दाएं पढ़ें: मुझे बाईं तालिका की सभी चीजें चाहिए), अधिकांश डेवलपर्स राइट जॉइन से बचते हैं और लेफ्ट जॉइन का उपयोग करने के लिए तालिकाओं को फिर से व्यवस्थित करते हैं। परिणाम समान हैं; यह एक कोड पठनीयता सम्मेलन है।
94
EN + हिं Easy
GB In query optimization what is join reordering with cross-product avoidance and why must the optimizer avoid cross-products?
IN क्वेरी ऑप्टिमाइज़ेशन में क्रॉस-प्रोडक्ट अवॉइडेंस के साथ जॉइन रीऑर्डरिंग क्या है और ऑप्टिमाइज़र को क्रॉस-प्रोडक्ट्स से क्यों बचना चाहिए?
A
Avoiding the use of Cartesian product notation कार्टेशियन उत्पाद संकेतन के उपयोग से बचना
B
The optimizer ensures that cross products (joins with no condition between two tables) are avoided or placed last in the join tree since they produce n times m rows with no filtering - immediately followed by a filter is converted to a join ऑप्टिमाइज़र यह सुनिश्चित करता है कि क्रॉस उत्पाद (दो तालिकाओं के बीच बिना किसी शर्त के जुड़ते हैं) को टाला जाता है या ज्वाइन ट्री में अंतिम स्थान पर रखा जाता है क्योंकि वे बिना किसी फ़िल्टरिंग के n गुना m पंक्तियों का उत्पादन करते हैं - इसके तुरंत बाद एक फ़िल्टर को एक जोड़ में बदल दिया जाता है
C
Reordering joins to be in alphabetical order पुनः क्रमित करना वर्णानुक्रम में जुड़ना है
D
Removing all cross products from query plans क्वेरी योजनाओं से सभी क्रॉस उत्पादों को हटाना
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Optimizer cross-product avoidance: in a WHERE clause, identify join conditions between tables. Group tables that have direct join conditions together. Tables with no direct join conditions connected via a cross product - optimizer delays this until after other joins have reduced row counts. Cross product early = catastrophic performance.
व्याख्या (हिन्दी) ऑप्टिमाइज़र क्रॉस-प्रोडक्ट परिहार: WHERE क्लॉज में, तालिकाओं के बीच जुड़ने की स्थिति की पहचान करें। समूह तालिकाएँ जिनमें एक साथ सीधे जुड़ने की स्थितियाँ होती हैं। क्रॉस उत्पाद के माध्यम से जुड़े बिना किसी प्रत्यक्ष जुड़ाव की स्थिति वाली तालिकाएँ - ऑप्टिमाइज़र इसमें तब तक देरी करता है जब तक कि अन्य जुड़ने से पंक्ति की संख्या कम नहीं हो जाती। क्रॉस उत्पाद जल्दी = विनाशकारी प्रदर्शन।
95
EN + हिं Medium
GB What is the difference between INNER JOIN and WHERE clause joins (implicit join syntax)?
IN इनर जॉइन और व्हेयर क्लॉज जॉइन (अंतर्निहित जॉइन सिंटैक्स) के बीच क्या अंतर है?
A
INNER JOIN cannot be used with aggregate functions इनर जॉइन का उपयोग समग्र कार्यों के साथ नहीं किया जा सकता है
B
They are semantically identical in standard SQL - both produce the same result; but INNER JOIN (explicit syntax) is preferred because it clearly separates join conditions from filter conditions making code more readable and maintainable वे मानक SQL में शब्दार्थ की दृष्टि से समान हैं - दोनों समान परिणाम देते हैं; लेकिन इनर जॉइन (स्पष्ट वाक्यविन्यास) को प्राथमिकता दी जाती है क्योंकि यह स्पष्ट रूप से जॉइन शर्तों को फ़िल्टर स्थितियों से अलग करता है जिससे कोड अधिक पठनीय और रखरखाव योग्य हो जाता है
C
WHERE clause joins are faster than INNER JOIN जहां क्लॉज जॉइन इनर जॉइन से तेज होते हैं
D
WHERE clause joins support outer joins; INNER JOIN does not जहां खंड जुड़ता है, बाहरी जुड़ाव का समर्थन करता है; इनर जॉइन नहीं है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Implicit join: SELECT * FROM A, B WHERE A.id = B.a_id AND B.status = active. Explicit join: SELECT * FROM A INNER JOIN B ON A.id = B.a_id WHERE B.status = active. Both produce identical results. Explicit preferred because: separates join conditions (ON) from filter conditions (WHERE), clearer intent, required for outer joins.
व्याख्या (हिन्दी) अंतर्निहित जुड़ाव: A, B से * चुनें जहां A.id = B.a_id और B.status = सक्रिय है। स्पष्ट जुड़ाव: चुनें * ए इनर जॉइन बी से ए.आईडी = बी.ए_आईडी पर जहां बी.स्टेटस = सक्रिय। दोनों समान परिणाम देते हैं। स्पष्ट को प्राथमिकता दी जाती है क्योंकि: जुड़ने की स्थिति (ON) को फ़िल्टर की स्थिति (WHERE) से अलग करता है, स्पष्ट इरादा, बाहरी जुड़ाव के लिए आवश्यक है।
96
EN + हिं Easy
GB What is the merge join (sort-merge join) algorithm and under what conditions is it most efficient?
IN मर्ज जॉइन (सॉर्ट-मर्ज जॉइन) एल्गोरिदम क्या है और यह किन परिस्थितियों में सबसे कुशल है?
A
A join that merges two tables into one एक जोड़ जो दो तालिकाओं को एक में मिला देता है
B
A join algorithm that merges indexes एक जॉइन एल्गोरिदम जो इंडेक्स को मर्ज करता है
C
A join that only works when tables have the same number of rows एक जुड़ाव जो केवल तभी काम करता है जब तालिकाओं में पंक्तियों की संख्या समान हो
D
A join algorithm that sorts both input relations on the join attribute then merges them in a single linear scan; most efficient when: both inputs are already sorted on the join attribute or when sorting is needed anyway (the sort cost is amortized) or when the join result is large एक जॉइन एल्गोरिदम जो जॉइन विशेषता पर दोनों इनपुट संबंधों को सॉर्ट करता है और फिर उन्हें एक एकल रैखिक स्कैन में विलय कर देता है; सबसे कुशल तब जब: दोनों इनपुट पहले से ही जॉइन विशेषता पर सॉर्ट किए गए हों या जब सॉर्टिंग की वैसे भी आवश्यकता हो (सॉर्ट लागत परिशोधित हो) या जब जॉइन परिणाम बड़ा हो
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Sort-merge join: (1) Sort R and S on join attribute (O(n log n + m log m)). (2) Merge: linearly scan both sorted relations simultaneously matching join keys (O(n+m)). Total: O(n log n + m log m). Most efficient: when inputs are pre-sorted (clustered index), when join is on primary key, or when result is large (hash join memory pressure).
व्याख्या (हिन्दी) सॉर्ट-मर्ज जॉइन: (1) जॉइन एट्रिब्यूट पर आर और एस को सॉर्ट करें (ओ(एन लॉग एन + एम लॉग एम))। (2) मर्ज: दोनों क्रमबद्ध संबंधों को एक साथ मिलान करने वाली जॉइन कुंजी (ओ (एन + एम)) को रैखिक रूप से स्कैन करें। कुल: ओ(एन लॉग एन + एम लॉग एम)। सबसे कुशल: जब इनपुट पूर्व-सॉर्ट किए जाते हैं (क्लस्टर इंडेक्स), जब जॉइन प्राथमिक कुंजी पर होता है, या जब परिणाम बड़ा होता है (हैश जॉइन मेमोरी प्रेशर)।
97
EN + हिं Medium
GB What is the difference between a hash join and a merge join in terms of memory requirements?
IN मेमोरी आवश्यकताओं के संदर्भ में हैश जॉइन और मर्ज जॉइन के बीच क्या अंतर है?
A
Merge join requires more memory than hash join मर्ज जॉइन के लिए हैश जॉइन की तुलना में अधिक मेमोरी की आवश्यकता होती है
B
They have identical memory requirements उनकी स्मृति आवश्यकताएँ समान हैं
C
Neither join algorithm uses memory कोई भी जॉइन एल्गोरिदम मेमोरी का उपयोग नहीं करता है
D
Hash join requires memory to store the entire smaller relation (build side) in a hash table - memory sensitive; merge join requires memory only for sort buffers - can spill to disk more gracefully; but merge join has higher CPU cost from sorting हैश जॉइन के लिए पूरे छोटे रिलेशन (बिल्ड साइड) को हैश टेबल में स्टोर करने के लिए मेमोरी की आवश्यकता होती है - मेमोरी सेंसिटिव; मर्ज जॉइन के लिए केवल सॉर्ट बफ़र्स के लिए मेमोरी की आवश्यकता होती है - डिस्क पर अधिक सुंदर ढंग से फैल सकता है; लेकिन मर्ज जॉइन में सॉर्टिंग से सीपीयू लागत अधिक होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Hash join: requires entire smaller table in memory (build phase). If it does not fit: grace hash join (partitioned to disk, more I/O). Memory sensitive. Merge join: requires sort buffers (can be small); external merge sort handles data larger than memory gracefully. Trade-off: hash join is faster when memory available; merge join more memory-resilient.
व्याख्या (हिन्दी) हैश जॉइन: मेमोरी में संपूर्ण छोटी तालिका की आवश्यकता होती है (बिल्ड चरण)। यदि यह फिट नहीं होता है: ग्रेस हैश जॉइन (डिस्क में विभाजित, अधिक I/O)। स्मृति संवेदनशील. मर्ज जॉइन: सॉर्ट बफ़र्स की आवश्यकता है (छोटा हो सकता है); बाहरी मर्ज सॉर्ट मेमोरी से बड़े डेटा को शानदार ढंग से संभालता है। ट्रेड-ऑफ़: मेमोरी उपलब्ध होने पर हैश जॉइन तेज़ होता है; मर्ज जॉइन अधिक मेमोरी-लचीला है।
98
EN + हिं Medium
GB What is the fanout problem in join optimization and how does it affect result set cardinality?
IN जॉइन ऑप्टिमाइज़ेशन में फैनआउट समस्या क्या है और यह परिणाम सेट कार्डिनैलिटी को कैसे प्रभावित करती है?
A
A performance issue when joining more than 10 tables 10 से अधिक तालिकाओं को जोड़ने पर एक प्रदर्शन समस्या
B
Too many tables in a single join एक ही जुड़ाव में बहुत सारी तालिकाएँ
C
A problem where join results have too few rows एक समस्या जहां जुड़ने के परिणामों में बहुत कम पंक्तियाँ हैं
D
When joining tables with M:N or 1:N relationships the result set can be much larger than the input tables due to row multiplication - e.g. joining Customers (1000 rows) to Orders (10000 rows) on 1:N relationship produces 10000 result rows not 1000 M:N या 1:N संबंधों के साथ तालिकाओं को जोड़ते समय पंक्ति गुणन के कारण परिणाम सेट इनपुट तालिकाओं से बहुत बड़ा हो सकता है - उदाहरण के लिए 1:N संबंध पर ग्राहकों (1000 पंक्तियों) को ऑर्डर (10000 पंक्तियों) से जोड़ने पर 1000 नहीं बल्कि 10000 परिणाम पंक्तियाँ उत्पन्न होती हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Fanout: each customer row fans out to multiple order rows in a 1:N join. For M:N joins (via junction table): even more fanout. This is why COUNT(*) after a join often returns more rows than expected. Solutions: GROUP BY to aggregate, DISTINCT to deduplicate, or restructure the query to avoid unnecessary fanout.
व्याख्या (हिन्दी) फ़ैनआउट: प्रत्येक ग्राहक पंक्ति 1:एन जॉइन में एकाधिक ऑर्डर पंक्तियों को फ़ैन करती है। एम:एन जॉइन के लिए (जंक्शन टेबल के माध्यम से): और भी अधिक फैनआउट। यही कारण है कि जुड़ने के बाद COUNT(*) अक्सर अपेक्षा से अधिक पंक्तियाँ लौटाता है। समाधान: एकत्रित करने के लिए ग्रुप BY, डुप्लिकेट हटाने के लिए DISTINCT, या अनावश्यक फैनआउट से बचने के लिए क्वेरी का पुनर्गठन करें।
99
EN + हिं Medium
GB What is the driving table concept in nested loop join execution and how does the optimizer choose it?
IN नेस्टेड लूप जॉइन निष्पादन में ड्राइविंग टेबल अवधारणा क्या है और ऑप्टिमाइज़र इसे कैसे चुनता है?
A
The driving table is always the first table listed in the FROM clause ड्राइविंग टेबल हमेशा FROM क्लॉज में सूचीबद्ध पहली टेबल होती है
B
In a nested loop join the driving table (outer loop) is the table whose rows are iterated one by one with the inner table looked up for each outer row; the optimizer chooses the smaller or more filtered table as the driving table to minimize iterations; an index on the inner table's join column is critical एक नेस्टेड लूप में ड्राइविंग टेबल से जुड़ें (बाहरी लूप) वह तालिका है जिसकी पंक्तियों को एक-एक करके दोहराया जाता है और प्रत्येक बाहरी पंक्ति के लिए आंतरिक तालिका देखी जाती है; ऑप्टिमाइज़र पुनरावृत्तियों को कम करने के लिए ड्राइविंग टेबल के रूप में छोटी या अधिक फ़िल्टर की गई तालिका को चुनता है; आंतरिक टेबल के जॉइन कॉलम पर एक इंडेक्स महत्वपूर्ण है
C
The table that drives the query plan in all join types always वह तालिका जो सभी प्रकार के जॉइन में हमेशा क्वेरी प्लान चलाती है
D
The driving table is always the larger table for maximum efficiency अधिकतम दक्षता के लिए ड्राइविंग टेबल हमेशा बड़ी टेबल होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Driving table selection: optimizer estimates rows returned by each table after applying WHERE filter, chooses smaller filtered result as outer (driving) table, verifies inner table has suitable index. Example: orders(10M rows) JOIN customers(100K rows) WHERE orders.date=2024 (returns 10K orders): driving=filtered orders(10K), inner=customers with index on id. If no index on customers.id: optimizer may switch to hash join.
व्याख्या (हिन्दी) ड्राइविंग टेबल चयन: ऑप्टिमाइज़र WHERE फ़िल्टर लागू करने के बाद प्रत्येक तालिका द्वारा लौटाई गई पंक्तियों का अनुमान लगाता है, बाहरी (ड्राइविंग) तालिका के रूप में छोटे फ़िल्टर किए गए परिणाम को चुनता है, सत्यापित करता है कि आंतरिक तालिका में उपयुक्त सूचकांक है। उदाहरण: ऑर्डर (10M पंक्तियाँ) ग्राहकों से जुड़ें (100K पंक्तियाँ) जहाँ ऑर्डर.डेट = 2024 (10K ऑर्डर लौटाता है): ड्राइविंग = फ़िल्टर किए गए ऑर्डर (10K), आंतरिक = आईडी पर इंडेक्स वाले ग्राहक। यदि customer.id पर कोई इंडेक्स नहीं है: ऑप्टिमाइज़र हैश जॉइन पर स्विच कर सकता है।
100
EN + हिं Medium
GB What is predicate pushdown through a join and why is it important for query performance?
IN जॉइन के माध्यम से प्रीडिकेट पुशडाउन क्या है और क्वेरी प्रदर्शन के लिए यह महत्वपूर्ण क्यों है?
A
Pushing predicates from subqueries to outer queries automatically सबक्वेरीज़ से बाहरी क्वेरीज़ की ओर स्वचालित रूप से विधेय को पुश करना
B
Pushing SQL predicates into stored procedures for reuse पुन: उपयोग के लिए संग्रहीत कार्यविधियों में SQL प्रेडिकेट को पुश करना
C
Moving predicates from WHERE to HAVING clause for correctness शुद्धता के लिए विधेय को WHERE से HAVING उपवाक्य की ओर ले जाना
D
Moving filter conditions (WHERE predicates) to be applied as early as possible in the execution plan - ideally directly on the base table scan before the join - so that fewer rows participate in the join operation; this is one of the most impactful query optimizer transformations and can reduce join input size by orders of magnitude निष्पादन योजना में जितनी जल्दी हो सके मूविंग फ़िल्टर शर्तों (जहां विधेय) को लागू किया जाना चाहिए - आदर्श रूप से सीधे जुड़ने से पहले बेस टेबल स्कैन पर - ताकि कम पंक्तियाँ जुड़ने के ऑपरेशन में भाग लें; यह सबसे प्रभावशाली क्वेरी ऑप्टिमाइज़र परिवर्तनों में से एक है और परिमाण के क्रम से जॉइन इनपुट आकार को कम कर सकता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Without pushdown: scan all orders (10M), scan all customers (1M), join, then filter WHERE orders.date=2024. With pushdown: filter orders first (10M -> 10K rows with date=2024), filter customers WHERE region=US (1M -> 100K), then join (10K * 100K). Pushdown blocked by: non-deterministic functions, LIMIT in subquery, some aggregate views. EXPLAIN shows Filter node placement.
व्याख्या (हिन्दी) पुशडाउन के बिना: सभी ऑर्डर स्कैन करें (10एम), सभी ग्राहकों को स्कैन करें (1एम), शामिल हों, फिर फ़िल्टर करें WHERE ऑर्डर.दिनांक=2024। पुशडाउन के साथ: पहले ऑर्डर फ़िल्टर करें (तारीख = 2024 के साथ 10M -> 10K पंक्तियाँ), ग्राहकों को फ़िल्टर करें जहाँ क्षेत्र = US (1M -> 100K), फिर जुड़ें (10K * 100K)। पुशडाउन द्वारा अवरुद्ध: गैर-नियतात्मक कार्य, सबक्वेरी में LIMIT, कुछ समग्र दृश्य। EXPLAIN फ़िल्टर नोड प्लेसमेंट दिखाता है।
101
EN + हिं Medium
GB What is a hash join spill and what happens when the build-side hash table does not fit in memory?
IN हैश जॉइन स्पिल क्या है और क्या होता है जब बिल्ड-साइड हैश टेबल मेमोरी में फिट नहीं होती है?
A
A hash join that overflows into another database automatically एक हैश जुड़ाव स्वचालित रूप से दूसरे डेटाबेस में ओवरफ्लो हो जाता है
B
When the build-side relation is too large to fit in the allocated hash join memory, the DBMS performs a grace hash join: partitions both relations to disk using the hash function (ensuring matching rows land in same partition files), then processes each partition pair independently in memory; this increases I/O but prevents out-of-memory errors जब बिल्ड-साइड संबंध आवंटित हैश जॉइन मेमोरी में फिट होने के लिए बहुत बड़ा है, तो डीबीएमएस एक ग्रेस हैश जॉइन करता है: हैश फ़ंक्शन का उपयोग करके डिस्क पर दोनों संबंधों को विभाजित करता है (सुनिश्चित करता है कि मिलान पंक्तियां समान विभाजन फ़ाइलों में आती हैं), फिर प्रत्येक विभाजन जोड़ी को मेमोरी में स्वतंत्र रूप से संसाधित करता है; यह I/O बढ़ाता है लेकिन आउट-ऑफ-मेमोरी त्रुटियों को रोकता है
C
A hash join that automatically converts to a nested loop join when memory is full एक हैश जॉइन जो मेमोरी भर जाने पर स्वचालित रूप से नेस्टेड लूप जॉइन में परिवर्तित हो जाता है
D
A hash join that produces incorrect results when data is too large एक हैश जॉइन जो डेटा बहुत बड़ा होने पर गलत परिणाम उत्पन्न करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Hash join memory: work_mem in PostgreSQL (default 4MB per sort/hash). If build table > work_mem: grace hash join kicks in. Cost: 3*(|R|+|S|) I/O pages vs 1*(|R|+|S|) for in-memory. Detection in EXPLAIN ANALYZE: Batches=N (N>1 means spill occurred). Fix: increase work_mem (SET work_mem=256MB), add filter to reduce build table size, or add index to use nested loop join instead.
व्याख्या (हिन्दी) हैश जॉइन मेमोरी: PostgreSQL में Work_mem (डिफ़ॉल्ट 4MB प्रति सॉर्ट/हैश)। यदि बिल्ड टेबल> वर्क_मेम: ग्रेस हैश जॉइन शुरू होता है। लागत: 3*(|R|+|S|) I/O पेज बनाम 1*(|R|+|S|) इन-मेमोरी के लिए। व्याख्या विश्लेषण में पता लगाना: बैच=एन (एन>1 का मतलब है रिसाव हुआ)। ठीक करें: वर्क_मेम बढ़ाएँ (SET वर्क_मेम=256एमबी), बिल्ड टेबल का आकार कम करने के लिए फ़िल्टर जोड़ें, या इसके बजाय नेस्टेड लूप जॉइन का उपयोग करने के लिए इंडेक्स जोड़ें।
102
EN + हिं Medium
GB What is the performance difference between NESTED LOOP JOIN HASH JOIN and SORT-MERGE JOIN?
IN नेस्टेड लूप जॉइन हैश जॉइन और सॉर्ट-मर्ज जॉइन के बीच प्रदर्शन में क्या अंतर है?
A
Nested Loop: O(n*m) good for small tables/indexed access; Hash Join: O(n+m) good for large unindexed tables (requires memory for hash table); Sort-Merge: O(n log n + m log m) good when inputs are already sorted नेस्टेड लूप: O(n*m) छोटी तालिकाओं/अनुक्रमित पहुंच के लिए अच्छा है; हैश जॉइन: O(n+m) बड़ी अनइंडेक्स्ड तालिकाओं के लिए अच्छा है (हैश तालिका के लिए मेमोरी की आवश्यकता होती है); सॉर्ट-मर्ज: O(n log n + m log m) अच्छा है जब इनपुट पहले से ही सॉर्ट किए गए हों
B
They are equally performant in all scenarios वे सभी परिदृश्यों में समान रूप से प्रदर्शन करते हैं
C
Nested Loop is always fastest नेस्टेड लूप हमेशा सबसे तेज़ होता है
D
Hash Join is always fastest हैश जॉइन हमेशा सबसे तेज़ होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Nested Loop: for each outer row, scan inner (use index). Best: small inner or indexed. Hash Join: build hash table on smaller table, probe with larger. Best: large unindexed tables. Sort-Merge: sort both, merge. Best: already-sorted inputs or when sort is needed anyway.
व्याख्या (हिन्दी) नेस्टेड लूप: प्रत्येक बाहरी पंक्ति के लिए, आंतरिक को स्कैन करें (इंडेक्स का उपयोग करें)। सर्वोत्तम: छोटा भीतरी या अनुक्रमित। हैश जॉइन: छोटी टेबल पर हैश टेबल बनाएं, बड़ी टेबल के साथ जांच करें। सर्वोत्तम: बड़ी अनअनुक्रमित तालिकाएँ। सॉर्ट-मर्ज: दोनों को सॉर्ट करें, मर्ज करें। सर्वोत्तम: पहले से ही क्रमबद्ध इनपुट या जब भी सॉर्ट की आवश्यकता हो।
103
EN + हिं Easy
GB In SQL what does a FULL OUTER JOIN return?
IN एसक्यूएल में फुल आउटर जॉइन क्या लौटाता है?
A
Only matching rows from both tables दोनों तालिकाओं से केवल मेल खाने वाली पंक्तियाँ
B
All rows from BOTH tables with NULLs for non-matching sides: rows matched on both sides (complete data) unmatched rows from left table (right side NULL) and unmatched rows from right table (left side NULL) गैर-मिलान पक्षों के लिए NULL के साथ दोनों तालिकाओं की सभी पंक्तियाँ: दोनों तरफ मिलान वाली पंक्तियाँ (पूर्ण डेटा), बाईं तालिका से बेजोड़ पंक्तियाँ (दाईं ओर NULL) और दाईं तालिका से बेजोड़ पंक्तियाँ (बाईं ओर NULL)
C
All rows from the left table only सभी पंक्तियाँ केवल बाईं तालिका से
D
All rows from neither table (only NULLs) किसी भी तालिका से सभी पंक्तियाँ (केवल शून्य)
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) FULL OUTER JOIN = LEFT OUTER JOIN UNION RIGHT OUTER JOIN. Result: (1) Rows matching join condition from both tables, (2) Left-only rows with NULL right columns, (3) Right-only rows with NULL left columns. Useful for: finding unmatched records in either table.
व्याख्या (हिन्दी) पूर्ण बाहरी जोड़ = बायां बाहरी जोड़ दायां बाहरी जोड़। परिणाम: (1) दोनों तालिकाओं से जुड़ने की स्थिति से मेल खाने वाली पंक्तियाँ, (2) केवल बाएँ पंक्तियाँ शून्य दाएँ स्तंभों के साथ, (3) केवल दाएँ पंक्तियाँ शून्य बाएँ स्तंभों के साथ। इसके लिए उपयोगी: किसी भी तालिका में बेजोड़ रिकॉर्ड ढूंढना।
104
EN + हिं Medium
GB What is the anti-join pattern and how is it implemented in SQL?
IN एंटी-जॉइन पैटर्न क्या है और इसे SQL में कैसे लागू किया जाता है?
A
A query pattern that returns rows from the left table that have NO matching rows in the right table implemented as: LEFT JOIN WHERE right.key IS NULL or NOT EXISTS (subquery) or NOT IN (subquery) एक क्वेरी पैटर्न जो बाईं तालिका से पंक्तियाँ लौटाता है, जिसमें दाहिनी तालिका में कोई मेल खाने वाली पंक्तियाँ नहीं हैं, इस प्रकार कार्यान्वित किया गया है: बाएँ शामिल हों जहाँ दाएँ.कुंजी शून्य है या मौजूद नहीं है (सबक्वेरी) या अंदर नहीं है (सबक्वेरी)
B
An outer join applied to all tables simultaneously एक बाहरी जोड़ सभी तालिकाओं पर एक साथ लागू होता है
C
A join that uses NOT EQUAL as the join condition एक जुड़ाव जो जुड़ने की शर्त के रूप में NOT EQUAL का उपयोग करता है
D
A join that reverses the join condition एक जुड़ाव जो जुड़ने की स्थिति को उलट देता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Anti-join: find customers with NO orders. Method 1: SELECT c.* FROM customer c LEFT JOIN order o ON c.id=o.cust_id WHERE o.cust_id IS NULL. Method 2: NOT EXISTS subquery. Method 3: NOT IN (subquery). Performance: LEFT JOIN+NULL check or NOT EXISTS usually preferred over NOT IN when NULLs may exist.
व्याख्या (हिन्दी) एंटी-जॉइन: बिना ऑर्डर वाले ग्राहक ढूंढें। विधि 1: ग्राहक से c.* चुनें c.id=o.cust_id पर शामिल होने का आदेश छोड़ दें जहां o.cust_id शून्य है। विधि 2: सबक्वेरी मौजूद नहीं है। विधि 3: नॉट इन (सबक्वेरी)। प्रदर्शन: लेफ्ट जॉइन+न्यूल चेक या NOT EXISTS को आम तौर पर NOT IN की तुलना में प्राथमिकता दी जाती है जब NULL मौजूद हो।
105
EN + हिं Easy
GB What is a join condition pushed down optimization and why does the optimizer do it?
IN जॉइन कंडीशन पुश डाउन ऑप्टिमाइज़ेशन क्या है और ऑप्टिमाइज़र ऐसा क्यों करता है?
A
Moving join conditions from ON to WHERE clause जुड़ने की शर्तों को ON से WHERE क्लॉज पर ले जाना
B
The query optimizer moves filtering conditions (predicates) as early as possible in the execution plan - before joining - to reduce the number of rows that need to be joined dramatically reducing the join cost क्वेरी ऑप्टिमाइज़र निष्पादन योजना में जितनी जल्दी हो सके फ़िल्टरिंग स्थितियों (विधेय) को स्थानांतरित करता है - शामिल होने से पहले - उन पंक्तियों की संख्या को कम करने के लिए जिन्हें नाटकीय रूप से शामिल करने की लागत को कम करने की आवश्यकता होती है।
C
Pushing join conditions from SQL to the application layer SQL से एप्लिकेशन लेयर पर जुड़ने की शर्तों को पुश करना
D
Moving join conditions from WHERE to HAVING जुड़ने की स्थिति को WHERE से HAVING की ओर ले जाना
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Predicate pushdown: instead of joining 1M rows then filtering, filter first (e.g., WHERE status=active) reducing to 10K rows, then join those. The optimizer rewrites the logical plan to apply filters before joins. Critical for performance, especially in distributed/columnar databases.
व्याख्या (हिन्दी) पुशडाउन की भविष्यवाणी करें: 1M पंक्तियों को जोड़ने और फिर फ़िल्टर करने के बजाय, पहले फ़िल्टर करें (उदाहरण के लिए, WHERE स्थिति=सक्रिय) 10K पंक्तियों तक कम करें, फिर उनमें शामिल हों। ऑप्टिमाइज़र जुड़ने से पहले फ़िल्टर लागू करने की तार्किक योजना को फिर से लिखता है। प्रदर्शन के लिए महत्वपूर्ण, विशेष रूप से वितरित/स्तंभकार डेटाबेस में।
91–105 of 146