2191

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% इंसर्ट/अपडेट सूचकांक को प्रभावित करते हैं), उच्च प्रभावी चयनात्मकता।

2192

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 स्क्रैच से पुनर्निर्माण करता है - ब्लोट को समाप्त करता है लेकिन टेबल को लॉक कर देता है।

2193

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 स्पष्ट हैश इंडेक्स का समर्थन करता है।

2194

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.

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

2195

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 बी-पेड़ों में से प्रत्येक को अपडेट करें। प्रत्येक बी-ट्री अपडेट नोड्स को विभाजित कर सकता है (कैस्केडिंग स्प्लिट्स)। लिखने-भारी कार्यभार के लिए: कम अनुक्रमणिका बेहतर है। एलएसएम-ट्री डेटाबेस (कैसेंड्रा, रॉक्सडीबी) मेमोरी में बैचिंग राइट्स द्वारा इसे कम करते हैं।

2196

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 पृष्ठ पढ़े जाते हैं।

2197

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% बड़ा सूचकांक।

2198

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 इस सूचकांक का उपयोग कर सकते हैं। इसके बिना: पूर्ण स्कैन (कॉलम पर फ़ंक्शन बी-ट्री सीक को अक्षम कर देता है)। इसके अलावा: वर्ष-आधारित प्रश्नों के लिए बिक्री पर सूचकांक (वर्ष (बिक्री_दिनांक)) बनाएं।

2199

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% स्थान को पूर्व-आवंटित करके विभाजन को रोकता है।

2200

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)। डीएमएल अभी भी इसे बनाए रखता है (अप-टू-डेट रहता है)। ऑप्टिमाइज़र इसका उपयोग नहीं करता है. केस का उपयोग करें: परीक्षण करें यदि मैं इस सूचकांक को छोड़ दूं तो क्या होगा? वास्तव में गिराए बिना। यदि ठीक है, तो छोड़ें। यदि समस्या हो तो तुरंत पुनः प्रदर्शित करें।

2201

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

2202

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) अद्यतन आँकड़ों का विश्लेषण करें।

2203

EN + हिं Medium

GB What is the difference between index seek and index scan in query execution plans?

IN क्वेरी निष्पादन योजनाओं में इंडेक्स सीक और इंडेक्स स्कैन के बीच क्या अंतर है?

A

Index scan is always faster than index seek इंडेक्स स्कैन हमेशा इंडेक्स सीक से तेज़ होता है

B

Index seek is for range queries; index scan for equality इंडेक्स सीक रेंज प्रश्नों के लिए है; समानता के लिए सूचकांक स्कैन

C

Index seek: uses the B-tree to navigate directly to the matching key value(s) - O(log n) + matching rows only. Index scan: reads all (or most) leaf pages of the index sequentially - O(index_size). Seek is much faster for selective queries; scan used when large fraction of data is returned or index cannot be used for point lookup इंडेक्स सीक: मिलान कुंजी मान (मानों) - ओ (लॉग एन) + केवल मिलान पंक्तियों पर सीधे नेविगेट करने के लिए बी-ट्री का उपयोग करता है। इंडेक्स स्कैन: इंडेक्स के सभी (या अधिकांश) लीफ पेजों को क्रमिक रूप से पढ़ता है - O(index_size)। चयनात्मक प्रश्नों के लिए सीक बहुत तेज़ है; स्कैन का उपयोग तब किया जाता है जब डेटा का बड़ा हिस्सा लौटाया जाता है या पॉइंट लुकअप के लिए इंडेक्स का उपयोग नहीं किया जा सकता है

D

Index seek is for non-indexed columns; index scan for indexed इंडेक्स सीक गैर-अनुक्रमित कॉलम के लिए है; अनुक्रमित के लिए सूचकांक स्कैन

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Seek: optimizer has a selective predicate (WHERE id=42) -> traverse B-tree from root to leaf O(log n). Fast for selective queries. Scan: predicate is not very selective or no matching index -> read all leaf pages sequentially. For covering index scans, scanning may still be efficient if sequential I/O.

व्याख्या (हिन्दी) खोजें: ऑप्टिमाइज़र के पास एक चयनात्मक विधेय है (जहां आईडी = 42) -> बी-ट्री को जड़ से पत्ती ओ (लॉग एन) तक पार करें। चयनात्मक प्रश्नों के लिए तेज़. स्कैन: विधेय बहुत चयनात्मक नहीं है या कोई मिलान सूचकांक नहीं है -> सभी पत्ती पृष्ठों को क्रमिक रूप से पढ़ें। इंडेक्स स्कैन को कवर करने के लिए, अनुक्रमिक I/O होने पर स्कैनिंग अभी भी कुशल हो सकती है।

2204

EN + हिं Easy

GB What is CREATE INDEX CONCURRENTLY in PostgreSQL and what trade-offs does it involve?

IN PostgreSQL में क्रिएट इंडेक्स समसामयिक रूप से क्या है और इसमें कौन से ट्रेड-ऑफ शामिल हैं?

A

Building an index without holding a table lock (allows concurrent reads AND writes during index build) - trade-offs: takes longer than normal index creation (multiple table scans needed) uses more CPU/I/O cannot be done in a transaction and may fail requiring manual REINDEX टेबल लॉक रखे बिना इंडेक्स बनाना (इंडेक्स निर्माण के दौरान समवर्ती पढ़ने और लिखने की अनुमति देता है) - ट्रेड-ऑफ: सामान्य इंडेक्स निर्माण से अधिक समय लगता है (एकाधिक टेबल स्कैन की आवश्यकता होती है) अधिक सीपीयू/आई/ओ का उपयोग लेनदेन में नहीं किया जा सकता है और मैन्युअल रीइंडेक्स की आवश्यकता विफल हो सकती है

B

Creating an index across multiple concurrent sessions एकाधिक समवर्ती सत्रों में एक सूचकांक बनाना

C

Creating an index that only works for concurrent queries एक सूचकांक बनाना जो केवल समवर्ती प्रश्नों के लिए काम करता है

D

Creating multiple indexes simultaneously एक साथ कई इंडेक्स बनाना

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) CREATE INDEX CONCURRENTLY: avoids ACCESS EXCLUSIVE lock. Process: (1) Register index in catalog. (2) First table scan - build initial index. (3) Second scan - incorporate changes from DML during first scan. (4) Final validation. Takes 2-3x longer. Downside: cannot be in transaction, if fails leaves invalid index needing cleanup.

व्याख्या (हिन्दी) समवर्ती रूप से इंडेक्स बनाएं: एक्सेस एक्सक्लूसिव लॉक से बचें। प्रक्रिया: (1) कैटलॉग में सूचकांक पंजीकृत करें। (2) पहला टेबल स्कैन - प्रारंभिक सूचकांक बनाएं। (3) दूसरा स्कैन - पहले स्कैन के दौरान डीएमएल से परिवर्तन शामिल करें। (4) अंतिम सत्यापन. 2-3x अधिक समय लगता है. नकारात्मक पक्ष: लेनदेन में नहीं हो सकता, यदि विफल रहता है तो अमान्य सूचकांक को सफाई की आवश्यकता होती है।

2205

EN + हिं Easy

GB What is a GiST (Generalized Search Tree) index in PostgreSQL and what data types does it support?

IN PostgreSQL में GiST (सामान्यीकृत खोज वृक्ष) सूचकांक क्या है और यह किस डेटा प्रकार का समर्थन करता है?

A

An index for geographic spatial data only केवल भौगोलिक स्थानिक डेटा के लिए एक सूचकांक

B

An extensible index framework that supports a wide variety of data types and query operators beyond equality/comparison: geometric objects text search IP ranges JSON paths custom types - by allowing user-defined key types and split/union/penalty functions एक एक्स्टेंसिबल इंडेक्स फ्रेमवर्क जो समानता/तुलना से परे विभिन्न प्रकार के डेटा प्रकारों और क्वेरी ऑपरेटरों का समर्थन करता है: ज्यामितीय ऑब्जेक्ट टेक्स्ट खोज आईपी रेंज JSON पथ कस्टम प्रकार - उपयोगकर्ता-परिभाषित कुंजी प्रकारों और विभाजन/संघ/दंड कार्यों की अनुमति देकर

C

A special type of B-tree for integers only केवल पूर्णांकों के लिए एक विशेष प्रकार का बी-ट्री

D

A global index that spans multiple tables simultaneously एक वैश्विक सूचकांक जो एक साथ कई तालिकाओं को फैलाता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) GiST (Generalized Search Tree): framework for building balanced tree indexes on any data type. PostgreSQL uses GiST for: 2D geometric types (&&, @>, intersects), full-text search (tsvector), IP ranges (inet, cidr), interval overlaps. User can define custom GiST index types by implementing key functions.

व्याख्या (हिन्दी) GiST (सामान्यीकृत खोज ट्री): किसी भी डेटा प्रकार पर संतुलित ट्री इंडेक्स बनाने के लिए रूपरेखा। PostgreSQL इसके लिए GiST का उपयोग करता है: 2D ज्यामितीय प्रकार (&&, @>, प्रतिच्छेद), पूर्ण-पाठ खोज (tsvector), IP श्रेणियाँ (inet, cidr), अंतराल ओवरलैप। उपयोगकर्ता प्रमुख कार्यों को लागू करके कस्टम जीआईएसटी सूचकांक प्रकारों को परिभाषित कर सकता है।

DBMS — MCQ Practice