SQL मा index भनेको के हो? तपाईंले कहिले र कहिले प्रयोग गर्नु हुँदैन?

Question

Accepted Answer

एक **index** एक डेटा संरचना हो (सामान्यतः एक **B-tree**) जसले डेटाबेसलाई पूरै तालिका स्क्यान गर्न बिना छिटो पङ्क्तिहरू खोज्न दिन्छ — पुस्तकको अनुक्रम जस्तै। यसले indexed स्तम्भ(हरू)मा lookups, filters, joins, र sorts को गति नाटकीय रूपमा बढाउँछ, अतिरिक्त storage र ढिलो writes को लागतमा।

## Index कसरी मदद गर्छ

```sql
-- without an index on email, this scans EVERY row (slow on a big table) — O(n)
SELECT * FROM users WHERE email = 'ann@x.com';

-- create an index → the database can find the row directly — O(log n)
CREATE INDEX idx_users_email ON users(email);
-- now the same query uses the index → dramatically faster
```

Index बिना, डेटाबेसले **पूरै तालिका स्क्यान** गर्छ (हरेक पङ्क्ति जाँच गर्दै)। एकको साथ, यसले matching पङ्क्तिहरू logarithmic समयमा खोज्न B-tree मार्फत नेविगेट गर्छ — लाखौं पङ्क्तिहरू स्क्यान गर्ने र मुट्ठी भर lookups को बीचको भिन्नता।

## कहिले indexes प्रयोग गर्नुस्

```text
✓ Columns in WHERE clauses (frequently filtered)
✓ Columns used in JOINs (foreign keys especially)
✓ Columns in ORDER BY (sorting can use the index)
✓ Columns with high SELECTIVITY (many distinct values — email, id)
✓ Primary keys (auto-indexed) and unique constraints
```

## कहिले indexes प्रयोग गर्नु हुँदैन (trade-offs)

```text
✗ Columns rarely queried — wasted storage and write overhead
✗ Small tables — a full scan is already fast; an index adds no benefit
✗ Low-selectivity columns (e.g. a boolean with 2 values) — index barely helps
✗ Write-heavy columns — EVERY INSERT/UPDATE/DELETE must also update the indexes
  → too many indexes SLOW DOWN writes significantly
```

Indexes निःशुल्क छैनन्: तिनीहरू **storage खपत** गर्छन् र **writes ढिलो** गर्छन् (हरेक परिमार्जन सबै indexes अपडेट गर्नु पर्छ)। Over-indexing ले write प्रदर्शन हानि पुर्याउँछ।

## Composite र अन्य index प्रकारहरू

```sql
CREATE INDEX idx_users_country_name ON users(country, name);   -- COMPOSITE (multi-column)
-- helps WHERE country = ? AND name = ?, and WHERE country = ? (leftmost prefix)
-- but NOT WHERE name = ? alone (order matters!)

CREATE UNIQUE INDEX ...      -- enforces uniqueness
-- also: partial indexes, covering indexes, GIN/GiST (Postgres) for special data
```

## किन यो महत्त्वपूर्ण छ

Indexes डेटाबेस प्रदर्शनमा सबैभन्दा महत्त्वपूर्ण विषयहरू मध्ये एक हो — तिनीहरू queries छिटो गर्ने प्राथमिक उपकरण हो, र कहिले र कसरी प्रयोग गर्ने भनेर बुझ्नु डेटाबेससँग काम गर्ने जो कोहीको लागि आवश्यक ज्ञान हो।

मूल मान नाटकीय हो: indexes बिना, जो columns मा filter, join, वा sort गर्छन् तिनीहरूलाई **पूरै तालिका स्क्यान** आवश्यक हुन्छ (हरेक पङ्क्ति जाँच गर्दै — डेटा बढ्दा विनाशकारी रूपमा ढिलो), जबकि indexes यिनीहरूलाई छिटो logarithmic lookups मा परिणत गर्छन् — अक्सरै query मिलिसेकन्ड र सेकन्ड वा मिनेटको बीचको भिन्नता।

**कहिले index गर्नुस्** भनेर बुझ्नु (अक्सर-filter गरिएको WHERE स्तम्भहरू, JOIN/foreign-key स्तम्भहरू, ORDER BY स्तम्भहरू, उच्च-selectivity स्तम्भहरू) query प्रदर्शनको लागि मौलिक हो।

समान रूपमा महत्त्वपूर्ण भनेको **trade-offs र कहिले INDEX गर्नु हुँदैन** भनेर बुझ्नु: indexes storage खपत गर्छन् र, महत्त्वपूर्ण रूपमा, **writes ढिलो** गर्छन् (हरेक INSERT/UPDATE/DELETE सबै indexes अपडेट गर्नु पर्छ), त्यसैले over-indexing ले write प्रदर्शन हानि पुर्याउँछ, र indexes छोटो तालिकाहरू वा कम-selectivity स्तम्भहरूमा सीमित मान राख्छन्।

यो संतुलन — जो query गरिएको छ त्यसमा index गर्दै while over-indexing गर्न सक्ने छैन — एक मुख्य कौशल हो।

**Composite indexes** (multi-column, जहाँ स्तम्भ क्रम कुन queries को लागि मदद गर्छ भनेर असर गर्छ) को बारे जान्न व्यावहारिक index ज्ञान पूरा गर्छ।

डेटाबेस प्रश्नको प्रदर्शन वास्तविक अनुप्रयोगहरूको लागि महत्त्वपूर्ण भएकोले, र सही indexing (सही स्तम्भहरूमा सही indexes, read गति बनाम write लागत र storage को विरुद्ध संतुलन) सबैभन्दा प्रभावशाली डेटाबेस अनुकूलन भएकोले, indexes मास्टर गर्नु — कसरी काम गर्छन्, कहिले प्रयोग गर्नु हुँदैन, write/storage trade-offs, र composite indexes — प्रदर्शनशील डेटाबेसहरूको लागि मूल, उच्च-मान ज्ञान हो र सबैभन्दा महत्त्वपूर्ण र सामान्यतः-परीक्षण गरिएको डेटाबेस विषयहरू मध्ये एक हो।