1. Learning Outcomes#

2. Database Index का मूल विचार#

मान लीजिए किसी company की employees table में केवल 20 rows हैं।

ऐसी छोटी table में किसी employee को ढूँढना आसान है। Database कई rows देखकर भी जल्दी result दे सकता है।

लेकिन अब उसी table में 50 लाख employees हों।

आपको केवल यह employee ढूँढना है:

SELECT *
FROM employees
WHERE email = 'asha@example.com';

अगर database के पास email को जल्दी खोजने का कोई अतिरिक्त रास्ता नहीं है, तो उसे बहुत सारी rows examine करनी पड़ सकती हैं।

यहीं index काम आता है।

English Definition#

सरल Hindi में इसका अर्थ यह है:

Index table के data की एक अतिरिक्त searchable structure होती है, जिसकी मदद से database किसी required row तक जल्दी पहुँच सकता है।

Index actual table को replace नहीं करता।

Actual data table में ही रहता है।

Index database को यह समझने में मदद करता है कि required value से संबंधित row कहाँ मिल सकती है।

इसे किताब के पीछे दिए गए index जैसा समझ सकते हैं।

अगर 800-page की किताब में आपको केवल "Transactions" topic चाहिए, तो आप हर page पढ़ना शुरू नहीं करेंगे।

Book index आपको बताएगा कि वह topic किन pages पर है।

Database index भी इसी basic idea पर काम करता है:

search value → useful location/reference → required row

3. Table और Index का Relationship#

एक basic mental model देखते हैं।

मान लीजिए हमारे पास employees table है और email column पर index बनाया गया है।

इस flow को step-by-step समझिए:

1. Query किसी particular email को खोजती है।
2. Database relevant index का उपयोग कर सकता है।
3. Index matching key value खोजने में मदद करता है।
4. Index से matching row की location/reference मिलती है।
5. Database actual row table से प्राप्त करता है।

यहाँ सबसे महत्वपूर्ण बात यह है कि table और index अलग logical structures हैं, लेकिन दोनों आपस में related हैं।

Table में actual row data रहता है।

Index उस data तक जल्दी पहुँचने का रास्ता दे सकता है।

4. Index क्यों उपयोगी होता है#

बिना useful index के database को कई situations में बड़ी संख्या में rows examine करनी पड़ सकती हैं।

इसे beginner level पर ऐसे समझिए:

मान लीजिए table में 10,00,000 rows हैं।

Query है:

SELECT *
FROM customers
WHERE customer_id = 845721;

अगर customer_id पर suitable index मौजूद है, तो database को जरूरी नहीं कि हर row एक-एक करके examine करनी पड़े।

वह index के माध्यम से matching location तक पहुँच सकता है।

इससे बड़ी tables में data retrieval significantly faster हो सकती है।

लेकिन एक महत्वपूर्ण बात याद रखें:

इसलिए:

Index performance improve कर सकता है, लेकिन हर index हर query के लिए useful नहीं होता।

5. Indexed Column और Search Key#

जिस column को index में शामिल किया जाता है, उसे सामान्य रूप से indexed column कहा जा सकता है।

उदाहरण:

CREATE INDEX idx_employees_email
ON employees (email);

यहाँ:

• employees table है।
• email indexed column है।
• idx_employees_email index का नाम है।

अब query देखें:

SELECT *
FROM employees
WHERE email = 'asha@example.com';

यहाँ 'asha@example.com' वह value है जिसे database search कर रहा है।

Indexing के context में ऐसी searchable value को search key value के रूप में समझ सकते हैं।

सरल mental model:

• Indexed column: email
• Search condition: email = 'asha@example.com'
• Search key value: 'asha@example.com'

एक composite index में search key एक से अधिक columns से भी संबंधित हो सकती है।

6. Index से Data Retrieval कैसे बदलता है#

यह simplified flow देखिए:

यह diagram exact internal database algorithm नहीं दिखाता।

यह beginner mental model है।

Useful index होने पर database candidate rows तक जल्दी पहुँच सकता है।

Suitable index न होने पर database को ज्यादा rows examine करनी पड़ सकती हैं।

यही कारण है कि indexing बड़ी tables और frequently searched data के लिए महत्वपूर्ण performance technique है।

7. Single-Column Index#

जब index में केवल एक column शामिल होता है, उसे single-column index कहते हैं।

उदाहरण:

CREATE INDEX idx_customers_email
ON customers (email);

यह index केवल email column पर बनाया गया है।

अगर application में frequently ऐसी query चलती है:

SELECT *
FROM customers
WHERE email = 'rahul@example.com';

तो email index useful हो सकता है।

एक और example:

CREATE INDEX idx_orders_customer_id
ON orders (customer_id);

अगर application frequently किसी customer के orders खोजती है:

SELECT *
FROM orders
WHERE customer_id = 501;

तो customer_id index data retrieval में मदद कर सकता है।

लेकिन केवल इसलिए index मत बनाइए क्योंकि कोई column table में मौजूद है।

Index का उद्देश्य actual query workload को support करना है।

8. Composite Index#

कई बार query एक से अधिक columns पर depend करती है।

उदाहरण:

SELECT *
FROM employees
WHERE department = 'Sales'
  AND salary > 50000;

यहाँ दो columns महत्वपूर्ण हैं:

• department
• salary

इन दोनों columns को एक ही index में शामिल किया जा सकता है।

CREATE INDEX idx_employees_department_salary
ON employees (department, salary);

ऐसे index को composite index या multi-column index कहते हैं।

English Definition#

सरल Hindi में:

Composite index में एक ही index के अंदर दो या दो से अधिक columns रखे जाते हैं।

लेकिन यहाँ केवल columns का selection ही महत्वपूर्ण नहीं है।

उनका order भी महत्वपूर्ण है।

9. Composite Index में Column Order#

यह index देखें:

CREATE INDEX idx_employees_department_salary
ON employees (department, salary);

इस index का column order है:

1. department
2. salary

इसे (department, salary) index कह सकते हैं।

Beginner mental model के लिए मान लीजिए index values logically इस तरह organized दिखाई देती हैं:

पहले values department के आधार पर organized हैं।

फिर same department के अंदर salary की values आती हैं।

इसलिए यह query index के order के साथ अच्छी तरह align करती है:

SELECT *
FROM employees
WHERE department = 'Sales';

यह query भी इस index से benefit कर सकती है:

SELECT *
FROM employees
WHERE department = 'Sales'
  AND salary > 50000;

अब केवल salary पर query देखें:

SELECT *
FROM employees
WHERE salary > 50000;

इस query में leading column department use नहीं हुआ।

इसलिए (department, salary) composite index सामान्य रूप से salary-only search के लिए उतना directly useful नहीं होता जितना department से शुरू होने वाली search के लिए हो सकता है।

Exact behavior DBMS और optimizer पर depend करता है।

Column order के लिए practical सोच#

अगर application में सबसे common query है:

SELECT *
FROM employees
WHERE department = 'Sales'
  AND salary > 50000;

तो (department, salary) reasonable candidate हो सकता है।

लेकिन अगर application अक्सर पहले salary search करती है और department rarely use होता है, तो दूसरे order की जरूरत हो सकती है।

इसलिए composite index design करते समय केवल column names नहीं देखें।

Actual queries देखें।

10. Single-Column और Composite Index का अंतर#

दोनों का लक्ष्य एक ही है:

Database को useful search path देना।

अंतर यह है कि composite index multiple columns के combined query pattern को support कर सकता है।

11. Unique Index#

अब मान लीजिए application में प्रत्येक user का email unique होना चाहिए।

दो users का same email acceptable नहीं है।

ऐसी situation में unique index उपयोग किया जा सकता है।

CREATE UNIQUE INDEX idx_users_email
ON users (email);

English Definition#

सरल Hindi में:

Unique index search को support करने के साथ indexed value की uniqueness भी enforce करता है।

अगर email पर unique index है, तो duplicate email insert करने का प्रयास database reject कर सकता है।

उदाहरण के लिए पहले से यह value मौजूद है:

rahul@example.com

फिर उसी indexed key value को duplicate रूप में insert करने का प्रयास uniqueness rule को violate कर सकता है।

Unique index का मुख्य उद्देश्य केवल performance नहीं है।

यह data integrity में भी भूमिका निभा सकता है।

12. Index और SELECT Performance#

Indexes सबसे अधिक read operations के context में चर्चा किए जाते हैं।

विशेष रूप से:

SELECT *
FROM customers
WHERE email = 'neha@example.com';

Suitable email index database को matching rows जल्दी locate करने में मदद कर सकता है।

इसी प्रकार:

SELECT *
FROM orders
WHERE customer_id = 1001;

customer_id पर suitable index useful हो सकता है।

लेकिन index का फायदा data size और query pattern पर depend करता है।

Small table का example#

अगर table में केवल 20 rows हैं, तो table की rows सीधे examine करना बहुत inexpensive हो सकता है।

ऐसी स्थिति में optimizer index का उपयोग न करने का निर्णय ले सकता है।

Large table का example#

अगर table में करोड़ों rows हैं और query बहुत कम matching rows खोजती है, तो suitable index काफी valuable हो सकता है।

इसलिए index के बारे में केवल यह statement याद न करें:

"Index query को fast करता है।"

सही understanding यह है:

13. हर Column पर Index बनाना सही नहीं है#

Beginner के मन में natural idea आ सकता है:

"अगर index search fast करता है, तो हर column पर index बना देते हैं।"

लेकिन ऐसा करना अक्सर गलत design होता है।

Index free नहीं होता।

हर index:

• storage लेता है।
• database को maintain करना पड़ता है।
• write operations पर अतिरिक्त काम पैदा कर सकता है।
• unnecessary होने पर कोई meaningful query benefit नहीं देता।

इसलिए indexing का सही goal है:

Useful indexes बनाना, maximum indexes बनाना नहीं।

14. INSERT पर Index की Cost#

मान लीजिए employees table पर तीन indexes हैं।

जब नई employee row insert होती है, database को केवल table में नई row add करना ही पर्याप्त नहीं होता।

Relevant indexes में भी नई entries maintain करनी पड़ती हैं।

Simplified flow:

इसका अर्थ:

More indexes → potentially more maintenance work during INSERT.

इसलिए read-heavy system और write-heavy system की indexing needs अलग हो सकती हैं।

15. UPDATE पर Index की Cost#

मान लीजिए email indexed column है।

CREATE INDEX idx_customers_email
ON customers (email);

अब यह update चलती है:

UPDATE customers
SET email = 'newmail@example.com'
WHERE customer_id = 101;

यहाँ indexed value बदल रही है।

Database को table data के साथ email index की संबंधित entry भी maintain करनी पड़ती है।

अगर update केवल ऐसे column पर हो जो उस particular index में शामिल नहीं है, तो उस index की search key logically बदलने की जरूरत नहीं पड़ सकती।

Exact physical work DBMS implementation पर depend करता है।

इसलिए यह कहना अधिक सही है:

Indexed columns में changes index maintenance cost बढ़ा सकते हैं।

16. DELETE पर Index की Cost#

Row delete होने पर database को table से row remove करने के साथ relevant indexes से उसकी entries भी remove या update करनी पड़ सकती हैं।

Simplified idea:

इसलिए indexes read performance में मदद कर सकते हैं, लेकिन writes को free नहीं बनाते।

17. Read Performance और Write Cost का Trade-Off#

Indexing का सबसे महत्वपूर्ण practical concept यही trade-off है।

इसे एक line में याद रखें:

Indexes reads को improve कर सकते हैं, लेकिन writes और storage की cost बढ़ा सकते हैं।

18. बहुत अधिक Indexes की समस्या#

मान लीजिए एक table में 15 columns हैं और developer ने लगभग हर column पर अलग index बना दिया।

शुरू में ऐसा लग सकता है कि performance शानदार होनी चाहिए।

लेकिन अब हर insert के साथ कई indexes maintain करने पड़ सकते हैं।

कई updates expensive हो सकती हैं।

Storage usage बढ़ता है।

कुछ indexes शायद कभी किसी useful query में use ही न हों।

ऐसी situation को over-indexing कहा जा सकता है।

Practical database tuning में redundant और unused indexes की पहचान भी महत्वपूर्ण होती है।

19. किन Columns पर Index उपयोगी हो सकता है#

Index बनाने के लिए कोई single universal rule नहीं है।

फिर भी कुछ common candidates होते हैं।

Frequently searched columns#

अगर application बार-बार यह करती है:

SELECT *
FROM users
WHERE email = 'user@example.com';

तो email index candidate हो सकता है।

Frequently joined columns#

अगर tables frequently किसी foreign-key-like column पर join होती हैं, तो उस column पर index useful हो सकता है।

उदाहरण:

SELECT *
FROM orders o
JOIN customers c
    ON o.customer_id = c.customer_id;

orders.customer_id जैसे frequently joined column पर indexing useful हो सकती है।

Exact benefit query plan और DBMS पर depend करेगा।

Selective columns#

ऐसा column जिसमें बहुत अलग-अलग values हों, कई searches में अच्छा candidate हो सकता है।

उदाहरण:

• email
• employee_id
• order_number

अगर query किसी specific value को खोजती है, index बहुत कम candidate rows तक पहुँचने में मदद कर सकता है।

Frequently used multi-column search patterns#

अगर application repeatedly यह pattern use करती है:

SELECT *
FROM orders
WHERE customer_id = 501
  AND order_date = '2026-10-01';

तो workload के आधार पर (customer_id, order_date) composite index evaluate किया जा सकता है।

मुख्य बात:

Index table देखकर नहीं, query patterns देखकर design करें।

20. Low-Value या Unnecessary Indexes#

हर searchable column index के लायक नहीं होता।

बहुत कम distinct values वाला column#

मान लीजिए table में 10 लाख rows हैं और is_active column में केवल दो values हैं:

• 0
• 1

अगर दोनों values बड़ी संख्या में rows match करती हैं, तो अकेले इस column का index कई workloads में limited benefit दे सकता है।

लेकिन इसे absolute rule न मानें।

कुछ databases और specific query patterns में low-cardinality column भी useful हो सकता है।

इसलिए सही statement है:

Low-cardinality columns को blindly index नहीं करना चाहिए।

Query में उपयोग न होने वाला column#

अगर कोई column कभी filtering, joining या relevant lookup में use ही नहीं होता, तो उस पर index बनाने से practical benefit कम हो सकता है।

बहुत छोटी table#

बहुत छोटी table में direct table scan इतना cheap हो सकता है कि extra index की आवश्यकता कम हो।

Frequently changed indexed column#

अगर indexed column बहुत frequently बदलता है, तो maintenance cost बढ़ सकती है।

यह जरूरी नहीं कि index गलत ही हो।

लेकिन read benefit और write cost compare करना चाहिए।

21. Index चुनने का Practical Decision Model#

Index create करने से पहले यह simple sequence सोचें:

इस flow में पहला step बहुत महत्वपूर्ण है:

Observe actual queries.

Indexing guesswork पर आधारित नहीं होनी चाहिए।

अगर query workload बदलता है, indexing strategy भी बदल सकती है।

22. Single-Column Index चुनें या Composite Index#

मान लीजिए application में ये queries frequently चलती हैं:

SELECT *
FROM employees
WHERE department = 'Sales';

और:

SELECT *
FROM employees
WHERE department = 'Sales'
  AND salary > 60000;

ऐसे workload में (department, salary) composite index useful candidate हो सकता है।

लेकिन अगर application separately बहुत अधिक salary-only queries चलाती है:

SELECT *
FROM employees
WHERE salary > 60000;

तो केवल existing composite index पर भरोसा करना सही assumption नहीं होगा।

Actual query workload और execution plans evaluate करने पड़ते हैं।

23. एक Practical Example#

मान लीजिए हमारे पास customers table है:

Production में यह table लाखों rows की हो सकती है।

Application frequently customer को email से खोजती है:

SELECT customer_id, name, email
FROM customers
WHERE email = 'rahul@example.com';

ऐसी situation में:

CREATE INDEX idx_customers_email
ON customers (email);

एक reasonable index candidate हो सकता है।

अगर business rule यह भी कहता है कि एक email केवल एक customer के लिए allowed है, तो ordinary index के बजाय unique index appropriate हो सकता है:

CREATE UNIQUE INDEX idx_customers_email
ON customers (email);

लेकिन दोनों statements को same database पर एक साथ blindly execute करने की जरूरत नहीं है।

यदि unique index requirement satisfy करता है, तो वही relevant search path और uniqueness दोनों purposes serve कर सकता है, DBMS behavior के अनुसार।

24. Common Beginner Mistakes#

Mistake 1: Index हमेशा query को fast करेगा#

यह गलत assumption है।

हर query के लिए हर index useful नहीं होता।

Database optimizer suitable execution strategy चुनता है।

Mistake 2: हर column पर index बनाना#

इससे unnecessary storage और write overhead बढ़ सकता है।

Mistake 3: Composite index में column order ignore करना#

(department, salary) और (salary, department) अलग index designs हैं।

Mistake 4: केवल SELECT performance देखना#

Indexes के कारण writes और storage पर भी cost आती है।

Mistake 5: Low-cardinality column को automatically useless मान लेना#

Low-cardinality column अक्सर weak standalone candidate हो सकता है, लेकिन actual usefulness workload और DBMS पर depend करती है।

Mistake 6: Index बनाकर performance assume कर लेना#

Production tuning में actual query behavior और execution plans measure करना बेहतर approach है।

25. Interview Preparation#

26. Chapter Recap#

इस chapter से ये core points याद रखें:

• Index database को certain rows जल्दी locate करने में मदद करता है।
• Actual data table में रहता है; index एक additional searchable structure है।
• Index में one or more table columns शामिल हो सकते हैं।
• Single-column index एक column पर आधारित होता है।
• Composite index multiple columns पर आधारित होता है।
• Composite index में column order बहुत महत्वपूर्ण है।
• Unique index indexed key values की uniqueness enforce कर सकता है।
• Suitable indexes SELECT queries को faster बना सकते हैं।
• Indexes free नहीं होते; उन्हें storage और maintenance चाहिए।
• INSERT, UPDATE, और DELETE के दौरान relevant indexes maintain करने पड़ सकते हैं।
• बहुत अधिक indexes write performance और storage पर negative effect डाल सकते हैं।
• Frequently searched, joined या selective columns indexing के अच्छे candidates हो सकते हैं।
• Low-value, unused या unnecessary columns पर blindly index नहीं बनाना चाहिए।
• सबसे अच्छा index वही है जो actual query workload को useful benefit देता है।