ایندکس‌گذاری دیتابیس
ایندکس دیتابیس: B-Tree و ساختار آن، ایندکس ترکیبی، هزینه‌های ایندکس و قواعد بهینه‌سازی کوئری
ایندکس چیست؟
بدون ایندکس، جستجوی کاربر = اسکن کل جدول (O(n)) — با ۱۰۰M رکورد یعنی ثانیه‌ها! ایندکس = ساختار داده‌ای جدا برای «یافتن سریع» — O(log n).
B-Tree — پادشاه ایندکس‌ها
درخت متوازن با پر بودن صفحات دیسک:
- جستجو: O(log n) — ۱۰۰M رکورد = ~۳ مقایسه سطح!
- درج/حذف: متوازن می‌ماند (خود-متوازن)
- پشتیبانی از بازه: WHERE age BETWEEN 20 AND 30 ✓
همان BST از دوره DSA، اما با شاخه‌های چندتایی (نه دوتایی) و بهینه دیسک!
ایندکس ترکیبی (Composite)
ایندکس روی (user_id, created_at):
- WHERE user_id = ? ✓
- WHERE user_id = ? AND created_at > ? ✓✓ (هر دو!)
- WHERE created_at = ? ✗ (فقط ستون دوم!)
قاعده ترتیب: ستون «انتخابی‌تر» (equality) اول، بازه‌ای آخر — مثل دفترچه تلفن: اول نام خانوادگی، بعد نام.
هزینه‌های ایندکس
ایندکس مجانی نیست:
| هزینه | توضیح |
|---|---|
| فضا | هر ایندکس = کپی بخشی از داده |
| نوشتن کندتر | هر INSERT/UPDATE = به‌روزرسانی همه ایندکس‌ها! |
| انتخاب بد | ایندکس بی‌استفاده = بار اضافه |
قاعده: ایندکس برای الگوی «خواندن غالب» — جدول نوشتنی سنگین، ایندکس کمتر!
قواعد طلایی
- ایندکس روی ستون‌های WHERE/JOIN/ORDER BY پرکاربرد
- ستون‌های با «کاردینالیتی بالا» (مقادیر متنوع) — ایندکس روی «جنسیت» بی‌فایده!
- کوئری را EXPLAIN کن — آیا ایندکس استفاده شد؟
- ایندکس بی‌استفاده را حذف کن (هزینه می‌دهد!)
- Covering Index: کوئری فقط از ایندکس جواب بگیرد (بدون جدول!)
نکته: در مصاحبه وقتی «کوئری کند» می‌گویند، اولین پاسخ: «EXPLAIN بگیریم، ایندکس مناسب روی ستون‌های فیلتر — ترکیبی با ترتیب درست». این پاسخ ۸۰٪ مسیر را می‌رود!
جمع‌بندی
- ایندکس = B-Tree برای جستجوی O(log n)
- ترکیبی: equality اول، بازه آخر
- هزینه: فضا + نوشتن کندتر
- EXPLAIN همیشه — حدس نزن، ببین!
این مبحث بخشی از دوره آموزش کامل طراحی سیستم (System Design) است.