1636

EN + हिं Easy

GB What is an index skip scan optimization and when does the optimizer use it?

IN इंडेक्स स्किप स्कैन ऑप्टिमाइज़ेशन क्या है और ऑप्टिमाइज़र इसका उपयोग कब करता है?

A

An optimization that skips leaf-level index scans एक अनुकूलन जो लीफ-लेवल इंडेक्स स्कैन को छोड़ देता है

B

An optimization for queries that skip every other row उन प्रश्नों के लिए एक अनुकूलन जो हर दूसरी पंक्ति को छोड़ देते हैं

C

An optimization where the query optimizer uses a composite index on (A B) to answer a query filtering only on B (not A) by logically splitting the scan into one sub-scan per distinct value of A - useful when A has low cardinality एक अनुकूलन जहां क्वेरी ऑप्टिमाइज़र एक क्वेरी का उत्तर देने के लिए (ए बी) पर एक समग्र सूचकांक का उपयोग करता है, केवल बी (ए नहीं) पर स्कैन को तार्किक रूप से ए के अलग-अलग मान के अनुसार एक उप-स्कैन में विभाजित करके फ़िल्टर करता है - जब ए में कम कार्डिनैलिटी होती है तो उपयोगी होता है

D

An optimization that skips indexes entirely एक अनुकूलन जो अनुक्रमणिका को पूरी तरह से छोड़ देता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Index skip scan: normally index(A,B) is useless for queries filtering only on B. With few distinct A values, optimizer can scan: A=val1 AND B=? + A=val2 AND B=? + ... (as many sub-scans as distinct A values). Efficient only when A has very few distinct values (say < 100).

व्याख्या (हिन्दी) इंडेक्स स्किप स्कैन: आम तौर पर इंडेक्स (ए, बी) केवल बी पर फ़िल्टर करने वाले प्रश्नों के लिए बेकार है। कुछ विशिष्ट ए मानों के साथ, ऑप्टिमाइज़र स्कैन कर सकता है: ए = वैल 1 और बी =? + ए=वैल2 और बी=? + ... (जितने अधिक उप-स्कैन, उतने ही विशिष्ट ए मान)। केवल तभी कुशल जब A के पास बहुत कम विशिष्ट मान हों (मान लें < 100)।

1637

EN + हिं Easy

GB What is the index merge optimization in MySQL and when does it apply?

IN MySQL में इंडेक्स मर्ज ऑप्टिमाइज़ेशन क्या है और यह कब लागू होता है?

A

Merging index entries from different B-trees विभिन्न बी-पेड़ों से सूचकांक प्रविष्टियों का विलय

B

Merging two indexes into one दो अनुक्रमणिकाओं को एक में विलय करना

C

An optimization for merging duplicate index entries डुप्लिकेट इंडेक्स प्रविष्टियों को मर्ज करने के लिए एक अनुकूलन

D

When the optimizer uses multiple separate indexes on a single table to satisfy a query and combines their results using intersection (AND) or union (OR) avoiding a full table scan when individual indexes are insufficient जब ऑप्टिमाइज़र किसी क्वेरी को संतुष्ट करने के लिए एक ही टेबल पर कई अलग-अलग इंडेक्स का उपयोग करता है और व्यक्तिगत इंडेक्स अपर्याप्त होने पर पूर्ण टेबल स्कैन से बचने के लिए इंटरसेक्शन (AND) या यूनियन (OR) का उपयोग करके उनके परिणामों को जोड़ता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Index merge: WHERE age>30 AND dept=Sales - two separate indexes (age, dept) can each return row IDs, then intersect (AND) the sets. Or: WHERE age>30 OR dept=Sales - union the sets. Less efficient than a single composite index but better than a full table scan if individual indexes are selective.

व्याख्या (हिन्दी) इंडेक्स मर्ज: जहां उम्र>30 और विभाग=बिक्री - दो अलग-अलग इंडेक्स (आयु, विभाग) प्रत्येक पंक्ति आईडी लौटा सकते हैं, फिर सेट को इंटरसेक्ट (और) कर सकते हैं। या: जहां आयु>30 या विभाग=बिक्री - सेटों का संघ। एकल समग्र सूचकांक की तुलना में कम कुशल लेकिन यदि व्यक्तिगत सूचकांक चयनात्मक हों तो पूर्ण तालिका स्कैन से बेहतर है।

1638

EN + हिं Easy

GB What is the leading column rule for composite indexes and why does it matter?

IN मिश्रित सूचकांकों के लिए अग्रणी स्तंभ नियम क्या है और यह क्यों मायने रखता है?

A

The leading column must have the highest cardinality अग्रणी कॉलम में उच्चतम कार्डिनैलिटी होनी चाहिए

B

The first column must be the primary key पहला कॉलम प्राथमिक कुंजी होना चाहिए

C

A composite index on (A B C) can only be used efficiently when the query filters include the leftmost prefix of columns (A or A+B or A+B+C) but NOT when filtering on B or C alone without A - the optimizer cannot use the index without the leading column (ए बी सी) पर एक समग्र सूचकांक का उपयोग केवल तभी कुशलता से किया जा सकता है जब क्वेरी फ़िल्टर में कॉलम (ए या ए + बी या ए + बी + सी) के सबसे बाएं उपसर्ग को शामिल किया जाता है, लेकिन ए के बिना अकेले बी या सी पर फ़िल्टर करते समय नहीं - ऑप्टिमाइज़र अग्रणी कॉलम के बिना सूचकांक का उपयोग नहीं कर सकता है

D

The leading column must be indexed separately as well अग्रणी कॉलम को भी अलग से अनुक्रमित किया जाना चाहिए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Composite index prefix rule: index(A,B,C) - useful for: WHERE A=x, WHERE A=x AND B=y, WHERE A=x AND B=y AND C=z. NOT useful for: WHERE B=y (no A), WHERE C=z (no A or B). Choose leading column as the one most commonly filtered. Plan index based on actual query patterns.

व्याख्या (हिन्दी) समग्र सूचकांक उपसर्ग नियम: सूचकांक (ए, बी, सी) - इसके लिए उपयोगी: जहां ए=एक्स, जहां ए=एक्स और बी=वाई, जहां ए=एक्स और बी=वाई और सी=जेड। इनके लिए उपयोगी नहीं है: जहां B=y (कोई A नहीं), जहां C=z (कोई A या B नहीं)। अग्रणी कॉलम को सबसे अधिक फ़िल्टर किए जाने वाले कॉलम के रूप में चुनें। वास्तविक क्वेरी पैटर्न के आधार पर योजना सूचकांक।

1639

EN + हिं Easy

GB What is a partial index (also called filtered index) and when is it beneficial?

IN आंशिक सूचकांक (जिसे फ़िल्टर्ड इंडेक्स भी कहा जाता है) क्या है और यह कब फायदेमंद है?

A

An index that only indexes part of the data physically एक सूचकांक जो डेटा के केवल भाग को भौतिक रूप से अनुक्रमित करता है

B

An index built incrementally over time समय के साथ क्रमिक रूप से निर्मित सूचकांक

C

An index that includes only rows satisfying a specified condition (WHERE clause) creating a smaller more efficient index for queries with that condition - e.g. CREATE INDEX ON orders(customer_id) WHERE status=pending एक सूचकांक जिसमें केवल एक निर्दिष्ट शर्त (WHERE क्लॉज) को संतुष्ट करने वाली पंक्तियाँ शामिल होती हैं, जो उस शर्त के साथ प्रश्नों के लिए एक छोटा और अधिक कुशल सूचकांक बनाती हैं - उदाहरण के लिए ऑर्डर पर इंडेक्स बनाएं (ग्राहक_आईडी) जहां स्थिति = लंबित है

D

An index on a subset of columns स्तंभों के उपसमूह पर एक सूचकांक

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Partial/filtered index: CREATE INDEX idx_active_users ON users(email) WHERE is_deleted=false. Only indexes non-deleted users (say 95% of queries). Benefits: smaller index (fits better in memory), faster maintenance (only 5% of inserts/updates affect the index), higher effective selectivity.

व्याख्या (हिन्दी) आंशिक/फ़िल्टर किया गया इंडेक्स: उपयोगकर्ताओं (ईमेल) पर इंडेक्स idx_active_users बनाएं जहां_हटाया गया = गलत है। केवल गैर-हटाए गए उपयोगकर्ताओं को अनुक्रमित करता है (मान लीजिए 95% प्रश्न)। लाभ: छोटा सूचकांक (मेमोरी में बेहतर फिट बैठता है), तेज रखरखाव (केवल 5% इंसर्ट/अपडेट सूचकांक को प्रभावित करते हैं), उच्च प्रभावी चयनात्मकता।

1640

EN + हिं Medium

GB What is the index bloat problem in PostgreSQL and how is it managed?

IN PostgreSQL में इंडेक्स ब्लोट समस्या क्या है और इसे कैसे प्रबंधित किया जाता है?

A

Indexes with too many levels in the B-tree बी-ट्री में बहुत अधिक स्तरों वाले सूचकांक

B

Indexes with too many duplicate values बहुत अधिक डुप्लिकेट मान वाले अनुक्रमणिका

C

Indexes accumulate dead tuples from UPDATE/DELETE operations (MVCC keeps old versions) causing the index size to grow beyond necessary degrading performance - managed by VACUUM (cleans dead tuples) REINDEX or CREATE INDEX CONCURRENTLY as replacement इंडेक्स अपडेट/डिलीट ऑपरेशंस (एमवीसीसी पुराने संस्करणों को रखता है) से मृत ट्यूपल्स को जमा करता है, जिससे इंडेक्स का आकार आवश्यक अपमानजनक प्रदर्शन से अधिक बढ़ जाता है - VACUUM द्वारा प्रबंधित (मृत ट्यूपल्स को साफ करता है) रीइंडेक्स या प्रतिस्थापन के रूप में समवर्ती रूप से इंडेक्स बनाएं

D

Indexes becoming too large due to data growth डेटा वृद्धि के कारण सूचकांक बहुत बड़े होते जा रहे हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) PostgreSQL MVCC: UPDATE creates new row version, old version left for concurrent readers. Index has entries for both old and dead versions. VACUUM removes dead tuples from heap AND marks index entries as dead (VACUUM also reclaims space). REINDEX rebuilds from scratch - eliminates bloat but locks table.

व्याख्या (हिन्दी) PostgreSQL MVCC: अद्यतन नई पंक्ति संस्करण बनाता है, पुराना संस्करण समवर्ती पाठकों के लिए छोड़ दिया जाता है। सूचकांक में पुराने और मृत दोनों संस्करणों की प्रविष्टियाँ हैं। VACUUM ढेर से मृत टुपल्स को हटा देता है और सूचकांक प्रविष्टियों को मृत के रूप में चिह्नित करता है (VACUUM भी स्थान पुनः प्राप्त करता है)। REINDEX स्क्रैच से पुनर्निर्माण करता है - ब्लोट को समाप्त करता है लेकिन टेबल को लॉक कर देता है।

1641

EN + हिं Easy

GB What is a hash index and in what scenarios is it superior to a B-tree index?

IN हैश इंडेक्स क्या है और किन परिदृश्यों में यह बी-ट्री इंडेक्स से बेहतर है?

A

A distributed index across multiple hash partitions एकाधिक हैश विभाजनों में एक वितरित सूचकांक

B

An index using a hash function to map key values to bucket positions - supports only equality lookups (O(1) average) but NOT range queries or ordering; superior for equality-only workloads with no range/ordering requirements प्रमुख मानों को बकेट स्थिति में मैप करने के लिए हैश फ़ंक्शन का उपयोग करने वाला एक सूचकांक - केवल समानता लुकअप (O(1) औसत) का समर्थन करता है, लेकिन श्रेणी क्वेरी या ऑर्डरिंग का नहीं; बिना किसी सीमा/ऑर्डरिंग आवश्यकताओं के केवल समानता वाले कार्यभार के लिए बेहतर

C

An index using a sorted hash table क्रमबद्ध हैश तालिका का उपयोग करने वाला एक सूचकांक

D

A B-tree index using hash-based key comparison हैश-आधारित कुंजी तुलना का उपयोग करते हुए एक बी-ट्री इंडेक्स

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Hash index: O(1) average for equality lookups (vs O(log n) for B-tree). No support for range queries, BETWEEN, ORDER BY, LIKE prefix (anything requiring ordering). MySQL InnoDB uses adaptive hash index (auto-built on frequently accessed B-tree entries). PostgreSQL supports explicit hash indexes.

व्याख्या (हिन्दी) हैश इंडेक्स: समानता लुकअप के लिए ओ(1) औसत (बी-ट्री के लिए बनाम ओ(लॉग एन))। रेंज क्वेरीज़, बीच, ऑर्डर बाय, लाइक प्रीफ़िक्स (कुछ भी ऑर्डर करने की आवश्यकता होती है) के लिए कोई समर्थन नहीं। MySQL InnoDB अनुकूली हैश इंडेक्स (अक्सर एक्सेस की गई बी-ट्री प्रविष्टियों पर स्वचालित रूप से निर्मित) का उपयोग करता है। PostgreSQL स्पष्ट हैश इंडेक्स का समर्थन करता है।

1642

EN + हिं Easy

GB What is the index-organized table (IOT) concept in Oracle?

IN Oracle में सूचकांक-संगठित तालिका (IOT) अवधारणा क्या है?

A

A table where the entire row data is stored within the index structure (B-tree leaf nodes) rather than in a separate heap file - eliminates the double storage of data (heap + index) provides fast primary key access but slower for full table scans and secondary index lookups एक तालिका जहां संपूर्ण पंक्ति डेटा को एक अलग हीप फ़ाइल के बजाय इंडेक्स संरचना (बी-ट्री लीफ नोड्स) के भीतर संग्रहीत किया जाता है - डेटा के दोहरे भंडारण को समाप्त करता है (हीप + इंडेक्स) तेजी से प्राथमिक कुंजी पहुंच प्रदान करता है लेकिन पूर्ण तालिका स्कैन और माध्यमिक इंडेक्स लुकअप के लिए धीमी गति से प्रदान करता है

B

A table that uses only indexes for storage एक तालिका जो भंडारण के लिए केवल अनुक्रमणिका का उपयोग करती है

C

A table where all columns are indexed एक तालिका जहां सभी कॉलम अनुक्रमित हैं

D

A table organized alphabetically by a string index एक स्ट्रिंग इंडेक्स द्वारा वर्णानुक्रम में व्यवस्थित एक तालिका

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) IOT/Clustered table: row data stored IN the B-tree leaf nodes of the primary key index. Benefits: eliminates heap lookup for PK queries. Drawbacks: secondary indexes store primary key (potentially large) as row locator, physical row order changes on PK updates, table scan traverses B-tree leaf pages.

व्याख्या (हिन्दी) आईओटी/क्लस्टर्ड तालिका: प्राथमिक कुंजी सूचकांक के बी-ट्री लीफ नोड्स में संग्रहीत पंक्ति डेटा। लाभ: पीके प्रश्नों के लिए ढेर लुकअप को समाप्त करता है। कमियां: द्वितीयक इंडेक्स प्राथमिक कुंजी (संभावित रूप से बड़ी) को पंक्ति लोकेटर के रूप में संग्रहीत करते हैं, पीके अपडेट पर भौतिक पंक्ति क्रम में परिवर्तन, टेबल स्कैन बी-ट्री लीफ पेजों को ट्रैवर्स करता है।

1643

EN + हिं Medium

GB What is the write amplification problem caused by indexes and how does it affect insert-heavy workloads?

IN इंडेक्स के कारण होने वाली राइट एम्प्लीफिकेशन समस्या क्या है और यह इन्सर्ट-हेवी वर्कलोड को कैसे प्रभावित करती है?

A

Amplifying the log file size लॉग फ़ाइल का आकार बढ़ाना

B

Each INSERT/UPDATE/DELETE on a table must also update ALL indexes on that table multiplying the write I/O: a table with 5 indexes requires writing to 6 places (heap + 5 indexes) per row change - significantly reduces write throughput in insert-heavy OLTP systems किसी टेबल पर प्रत्येक INSERT/UPDATE/DELETE को राइट I/O को गुणा करते हुए उस टेबल के सभी इंडेक्स को भी अपडेट करना होगा: 5 इंडेक्स वाली एक टेबल को प्रति पंक्ति परिवर्तन के लिए 6 स्थानों (हीप + 5 इंडेक्स) पर लिखने की आवश्यकता होती है - इन्सर्ट-हेवी ओएलटीपी सिस्टम में राइट थ्रूपुट को काफी कम कर देता है।

C

Writing the same data to multiple disk sectors एक ही डेटा को एकाधिक डिस्क सेक्टरों में लिखना

D

Amplifying write permissions across users उपयोगकर्ताओं के बीच लेखन अनुमतियाँ प्रवर्धित करना

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Write amplification: INSERT into table with 10 indexes: (1) write heap row, (2-11) update each of 10 B-trees. Each B-tree update may split nodes (cascading splits). For write-heavy workloads: fewer indexes is better. LSM-tree databases (Cassandra, RocksDB) mitigate this by batching writes in memory.

व्याख्या (हिन्दी) प्रवर्धन लिखें: 10 इंडेक्स वाली तालिका में डालें: (1) ढेर पंक्ति लिखें, (2-11) 10 बी-पेड़ों में से प्रत्येक को अपडेट करें। प्रत्येक बी-ट्री अपडेट नोड्स को विभाजित कर सकता है (कैस्केडिंग स्प्लिट्स)। लिखने-भारी कार्यभार के लिए: कम अनुक्रमणिका बेहतर है। एलएसएम-ट्री डेटाबेस (कैसेंड्रा, रॉक्सडीबी) मेमोरी में बैचिंग राइट्स द्वारा इसे कम करते हैं।

1644

EN + हिं Easy

GB What is the index-only scan optimization and what is required for it to be possible?

IN इंडेक्स-ओनली स्कैन ऑप्टिमाइज़ेशन क्या है और इसे संभव बनाने के लिए क्या आवश्यक है?

A

A scan that uses only the first index on a table एक स्कैन जो किसी टेबल पर केवल पहले इंडेक्स का उपयोग करता है

B

A scan that skips every other index entry एक स्कैन जो हर दूसरी इंडेक्स प्रविष्टि को छोड़ देता है

C

A query execution method where all required data is found directly in the index pages without accessing the table heap - requires that all columns referenced in the query (SELECT WHERE GROUP BY ORDER BY) are included in the index (covering index) एक क्वेरी निष्पादन विधि जहां सभी आवश्यक डेटा तालिका ढेर तक पहुंच के बिना सीधे इंडेक्स पेजों में पाया जाता है - आवश्यक है कि क्वेरी में संदर्भित सभी कॉलम (ऑर्डर बाय ग्रुप का चयन करें) इंडेक्स में शामिल हों (इंडेक्स को कवर करते हुए)

D

A scan that bypasses the index entirely एक स्कैन जो सूचकांक को पूरी तरह से बायपास कर देता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Index-only scan: if index on (a,b,c) and query SELECT a, b WHERE c=5 - all data (a,b,c) is in the index leaf. No heap access needed. In PostgreSQL: also requires checking the visibility map (for MVCC). Dramatically faster: index typically 10-100x smaller than heap, fewer I/O pages read.

व्याख्या (हिन्दी) इंडेक्स-ओनली स्कैन: यदि इंडेक्स (ए, बी, सी) पर है और क्वेरी ए, बी का चयन करती है जहां सी = 5 है - सभी डेटा (ए, बी, सी) इंडेक्स लीफ में है। ढेर पहुंच की आवश्यकता नहीं है. PostgreSQL में: दृश्यता मानचित्र (MVCC के लिए) की जाँच करने की भी आवश्यकता होती है। नाटकीय रूप से तेज़: सूचकांक आम तौर पर ढेर से 10-100 गुना छोटा होता है, कम I/O पृष्ठ पढ़े जाते हैं।

1645

EN + हिं Easy

GB What is the fill factor parameter in B-tree index creation and why would you set it below 100%?

IN बी-ट्री इंडेक्स निर्माण में भरण कारक पैरामीटर क्या है और आप इसे 100% से नीचे क्यों सेट करेंगे?

A

The compression ratio of the index data सूचकांक डेटा का संपीड़न अनुपात

B

The percentage of each index page that is filled with data at index creation time; setting below 100% (e.g. 80%) leaves free space in each page for future insertions reducing page splits - beneficial for frequently updated indexes at the cost of larger initial index size प्रत्येक सूचकांक पृष्ठ का प्रतिशत जो सूचकांक निर्माण के समय डेटा से भरा होता है; 100% से नीचे की सेटिंग (उदाहरण के लिए 80%) भविष्य के सम्मिलन के लिए प्रत्येक पृष्ठ में खाली स्थान छोड़ती है जिससे पृष्ठ विभाजन कम हो जाता है - बड़े प्रारंभिक सूचकांक आकार की कीमत पर बार-बार अद्यतन किए गए अनुक्रमित के लिए फायदेमंद

C

The percentage of disk space used by the index सूचकांक द्वारा प्रयुक्त डिस्क स्थान का प्रतिशत

D

The percentage of table rows that are indexed अनुक्रमित की गई तालिका पंक्तियों का प्रतिशत

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Fill factor: CREATE INDEX ... WITH (FILLFACTOR=80). Leaves 20% space in leaf pages. Benefit: new inserts/updates on nearby key values fit in existing pages (no page splits). Page splits are expensive (write new page, update parent, update sibling pointers). Trade-off: 20% larger index initially.

व्याख्या (हिन्दी) फ़ैक्टर भरें: इंडेक्स बनाएं... (फ़िलफ़ैक्टर=80) के साथ। पत्तों के पन्नों में 20% जगह छोड़ता है। लाभ: आस-पास के प्रमुख मानों पर नए इंसर्ट/अपडेट मौजूदा पृष्ठों में फिट होते हैं (कोई पृष्ठ विभाजन नहीं)। पेज विभाजन महंगे हैं (नया पेज लिखें, पेरेंट अपडेट करें, सिबलिंग पॉइंटर्स अपडेट करें)। ट्रेड-ऑफ़: प्रारंभ में 20% बड़ा सूचकांक।

1646

EN + हिं Easy

GB What is a functional index or expression index and provide an example?

IN कार्यात्मक सूचकांक या अभिव्यक्ति सूचकांक क्या है और एक उदाहरण प्रदान करें?

A

An index used by stored functions exclusively संग्रहीत फ़ंक्शंस द्वारा विशेष रूप से उपयोग किया जाने वाला एक सूचकांक

B

An index that applies functions during searches एक सूचकांक जो खोजों के दौरान फ़ंक्शन लागू करता है

C

An index built on the RESULT of an expression/function applied to one or more columns allowing efficient queries that filter/sort on computed values - e.g. CREATE INDEX ON users(LOWER(email)) enables case-insensitive email lookups to use the index एक अभिव्यक्ति/फ़ंक्शन के परिणाम पर निर्मित एक सूचकांक एक या अधिक कॉलम पर लागू होता है जो कुशल प्रश्नों की अनुमति देता है जो गणना किए गए मानों पर फ़िल्टर/सॉर्ट करते हैं - उदाहरण के लिए उपयोगकर्ताओं पर इंडेक्स बनाएं (कम (ईमेल)) इंडेक्स का उपयोग करने के लिए केस-असंवेदनशील ईमेल लुकअप को सक्षम बनाता है

D

An index created by a stored function संग्रहीत फ़ंक्शन द्वारा बनाया गया एक सूचकांक

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Expression index: CREATE INDEX idx_lower_email ON users(LOWER(email)). Then: SELECT * FROM users WHERE LOWER(email)=test@example.com can use this index. Without it: full scan (function on column disables B-tree seek). Also: CREATE INDEX ON sales(year(sale_date)) for year-based queries.

व्याख्या (हिन्दी) अभिव्यक्ति सूचकांक: उपयोगकर्ताओं पर सूचकांक idx_lower_email बनाएं (कम(ईमेल))। फिर: SELECT * FROM Users WHERE LOWER(email)=test@example.com इस सूचकांक का उपयोग कर सकते हैं। इसके बिना: पूर्ण स्कैन (कॉलम पर फ़ंक्शन बी-ट्री सीक को अक्षम कर देता है)। इसके अलावा: वर्ष-आधारित प्रश्नों के लिए बिक्री पर सूचकांक (वर्ष (बिक्री_दिनांक)) बनाएं।

1647

EN + हिं Medium

GB What is the page split problem in B-tree indexes and how does it affect performance?

IN बी-ट्री इंडेक्स में पेज स्प्लिट समस्या क्या है और यह प्रदर्शन को कैसे प्रभावित करती है?

A

A problem when the index spans multiple disk pages एक समस्या जब सूचकांक एकाधिक डिस्क पृष्ठों तक फैला होता है

B

Physical disk page corruption during index update सूचकांक अद्यतन के दौरान भौतिक डिस्क पृष्ठ भ्रष्टाचार

C

When a B-tree leaf page is full and a new key must be inserted the page splits into two pages (50/50 distribution) requiring: allocating new page redistributing keys updating parent pointer possibly cascading parent splits - causes write I/O overhead and index fragmentation जब बी-ट्री लीफ पेज पूरा भर जाता है और एक नई कुंजी डाली जानी चाहिए तो पेज दो पेजों (50/50 वितरण) में विभाजित हो जाता है: नए पेज को आवंटित करना, कुंजी को पुनर्वितरित करना, पैरेंट पॉइंटर को अपडेट करना, संभवतः पैरेंट स्प्लिट्स को कैस्केडिंग करना - I/O ओवरहेड और इंडेक्स फ़्रेग्मेंटेशन लिखने का कारण बनता है

D

A split in the B-tree caused by DELETE operations DELETE परिचालन के कारण बी-ट्री में विभाजन

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Page split: leaf page 100% full + new insert -> split: create new page, move ~50% of keys to new page, update parent with new separator key, parent may also split (cascade). Results: fragmented index (pages 50% full), more I/O to read. Fill factor < 100% prevents splits by pre-allocating space.

व्याख्या (हिन्दी) पेज स्प्लिट: लीफ पेज 100% पूर्ण + नया इंसर्ट -> स्प्लिट: नया पेज बनाएं, ~50% कुंजियों को नए पेज पर ले जाएं, नई विभाजक कुंजी के साथ पैरेंट को अपडेट करें, पैरेंट भी विभाजित (कैस्केड) हो सकता है। परिणाम: खंडित सूचकांक (पृष्ठ 50% पूर्ण), पढ़ने के लिए अधिक I/O। भरण कारक <100% स्थान को पूर्व-आवंटित करके विभाजन को रोकता है।

1648

EN + हिं Easy

GB What is the invisible index feature in Oracle/MySQL and what is its use case?

IN Oracle/MySQL में अदृश्य सूचकांक सुविधा क्या है और इसका उपयोग मामला क्या है?

A

An index that the optimizer ignores (as if it does not exist) but is still maintained by DML operations - used to safely test the impact of dropping an index without actually removing it or to prepare a new index for testing before making it active एक सूचकांक जिसे ऑप्टिमाइज़र अनदेखा करता है (जैसे कि यह अस्तित्व में नहीं है) लेकिन अभी भी डीएमएल संचालन द्वारा बनाए रखा जाता है - वास्तव में इसे हटाए बिना किसी सूचकांक को छोड़ने के प्रभाव का सुरक्षित रूप से परीक्षण करने या इसे सक्रिय करने से पहले परीक्षण के लिए एक नया सूचकांक तैयार करने के लिए उपयोग किया जाता है

B

An index hidden from users but visible to the optimizer एक सूचकांक जो उपयोगकर्ताओं से छिपा हुआ है लेकिन अनुकूलक को दिखाई देता है

C

An index with encrypted entries एन्क्रिप्टेड प्रविष्टियों वाला एक सूचकांक

D

An index that is physically hidden on secondary storage एक सूचकांक जो द्वितीयक भंडारण पर भौतिक रूप से छिपा होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Invisible/disabled index: ALTER INDEX idx INVISIBLE (Oracle) / ALTER TABLE t ALTER INDEX idx INVISIBLE (MySQL 8.0). DML still maintains it (stays up-to-date). Optimizer does not use it. Use case: test what if I drop this index? without actually dropping. If OK, drop. If problems, make visible again immediately.

व्याख्या (हिन्दी) अदृश्य/अक्षम सूचकांक: परिवर्तन सूचकांक आईडीएक्स अदृश्य (ओरेकल) / परिवर्तन तालिका टी परिवर्तन सूचकांक आईडीएक्स अदृश्य (MySQL 8.0)। डीएमएल अभी भी इसे बनाए रखता है (अप-टू-डेट रहता है)। ऑप्टिमाइज़र इसका उपयोग नहीं करता है. केस का उपयोग करें: परीक्षण करें यदि मैं इस सूचकांक को छोड़ दूं तो क्या होगा? वास्तव में गिराए बिना। यदि ठीक है, तो छोड़ें। यदि समस्या हो तो तुरंत पुनः प्रदर्शित करें।

1649

EN + हिं Easy

GB What is a reverse key index in Oracle and what problem does it solve?

IN Oracle में रिवर्स की इंडेक्स क्या है और यह किस समस्या का समाधान करता है?

A

An index that searches backwards through the B-tree एक सूचकांक जो बी-ट्री के माध्यम से पीछे की ओर खोज करता है

B

An index that stores rows in reverse insertion order एक सूचकांक जो पंक्तियों को विपरीत प्रविष्टि क्रम में संग्रहीत करता है

C

An index where the bytes of the key are reversed before storage in the B-tree distributing sequential key inserts (like auto-increment IDs) across all index leaf blocks instead of always inserting into the rightmost block - reduces right-hand-side contention in OLTP systems एक इंडेक्स जहां कुंजी के बाइट्स को बी-ट्री में भंडारण से पहले उलट दिया जाता है, जो हमेशा सबसे दाहिने ब्लॉक में डालने के बजाय सभी इंडेक्स लीफ ब्लॉक में अनुक्रमिक कुंजी इंसर्ट (जैसे ऑटो-इंक्रीमेंट आईडी) वितरित करता है - ओएलटीपी सिस्टम में दाईं ओर के विवाद को कम करता है

D

An index with keys stored in reverse alphabetical order विपरीत वर्णमाला क्रम में संग्रहीत कुंजियों वाला एक सूचकांक

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Reverse key index: seq key 1234 stored as 4321. Prevents hot-spot on rightmost leaf page when inserting sequential keys (all threads compete for same page). Distributes inserts across all leaf pages. Downside: range queries impossible (sequential keys are no longer adjacent in index).

व्याख्या (हिन्दी) रिवर्स कुंजी सूचकांक: seq कुंजी 1234 को 4321 के रूप में संग्रहीत किया जाता है। अनुक्रमिक कुंजियाँ सम्मिलित करते समय सबसे दाएँ पृष्ठ पृष्ठ पर हॉट-स्पॉट को रोकता है (सभी थ्रेड एक ही पृष्ठ के लिए प्रतिस्पर्धा करते हैं)। सभी लीफ पेजों पर इंसर्ट वितरित करता है। नकारात्मक पक्ष: श्रेणी क्वेरी असंभव है (अनुक्रमिक कुंजियाँ अब सूचकांक में आसन्न नहीं हैं)।

1650

EN + हिं Easy

GB What are index statistics and why are they critical for query optimization?

IN सूचकांक आँकड़े क्या हैं और वे क्वेरी अनुकूलन के लिए महत्वपूर्ण क्यों हैं?

A

Statistical information about index column value distribution (cardinality histograms null count average row size) that the query optimizer uses to estimate result sizes and costs for different execution plan choices - stale or inaccurate statistics lead to poor plan choices सूचकांक स्तंभ मूल्य वितरण के बारे में सांख्यिकीय जानकारी (कार्डिनैलिटी हिस्टोग्राम शून्य गणना औसत पंक्ति आकार) जिसका उपयोग क्वेरी ऑप्टिमाइज़र विभिन्न निष्पादन योजना विकल्पों के लिए परिणाम आकार और लागत का अनुमान लगाने के लिए करता है - पुराने या गलत आँकड़े खराब योजना विकल्पों का कारण बनते हैं

B

The storage statistics for index pages अनुक्रमणिका पृष्ठों के लिए भंडारण आँकड़े

C

The timing statistics for index lookup operations इंडेक्स लुकअप ऑपरेशन के लिए समय आँकड़े

D

The count of distinct values in an index किसी सूचकांक में भिन्न मानों की गिनती

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Index statistics: the optimizer uses cardinality (distinct values), histograms (value distribution), null percentage, correlation (physical sort order vs. key order). Used to estimate: rows returned by predicate, join selectivity, cost of index scan vs. full scan. ANALYZE TABLE (MySQL) / ANALYZE (PostgreSQL) updates statistics.

व्याख्या (हिन्दी) सूचकांक आँकड़े: ऑप्टिमाइज़र कार्डिनैलिटी (विशिष्ट मान), हिस्टोग्राम (मूल्य वितरण), शून्य प्रतिशत, सहसंबंध (भौतिक क्रम क्रम बनाम कुंजी क्रम) का उपयोग करता है। अनुमान लगाने के लिए उपयोग किया जाता है: विधेय द्वारा लौटाई गई पंक्तियाँ, चयनात्मकता में शामिल होना, सूचकांक स्कैन बनाम पूर्ण स्कैन की लागत। तालिका (MySQL) का विश्लेषण करें / (PostgreSQL) अद्यतन आँकड़ों का विश्लेषण करें।

DBMS — MCQ Practice