بازگشت به کتابخانهکتابخانه3.2Index: چرا کوئری‌ها سریع‌اند
طراحی سیستم نرم‌افزاریSYSTEM DESIGNاز صفر تا تسلط
v1.0.0
01مبانی و تصویر بزرگ
02Scalability و ظرفیت
03لایه داده
04Cache، Queue و جریان
05معماری نرم‌افزار
06قابلیت اطمینان و عملیات
07متد طراحی
08Case Study های واقعی
09سیستم‌های توزیع‌شده عمیق
10مهندسی تولید: داده، امنیت و کارایی
11تمرین پیشرفته و کیس‌استادی‌های مکمل
12زیر کاپوت دیتابیس و معماری داده
13وب بلادرنگ و پروتکل‌های مدرن
14سیستم‌های توزیع‌شده پیشرفته
15SaaS ،SRE ،امنیت و شبکه پیشرفته
16طراحی سیستم در عصر AI
17Case Study های تکمیلی
LESSON 3.2فصل ۳لایه داده

Index: چرا کوئری‌ها سریع‌اند

  • ~۹ دقیقه
  • ۴ پرسش
  • متن را انتخاب کن تا هایلایت شود

کتابفروشی صد هزار جلد دارد. مشتری می‌گوید «همه کتاب‌های همین نویسنده». اگر قفسه‌ها را از اول تا آخر بگردی، ظهر تمام می‌شود. یک کارت‌کاتالوگ کنار در می‌گذاری: نام نویسنده → شماره قفسه. اسم این فهرست Index است.

Index یک ساختار جانبی است — معمولاً B-Tree — که به‌جای گشتن کل جدول، میان‌بر می‌دهد. جستجو از O(n) می‌شود O(log n). در جدول ۱۰۰ میلیونی، فرق 10ms با دو دقیقه است. بدون آن، دیتابیس هر بار Full Table Scan می‌کند: هر قفسه، هر جلد.

قفسه‌گردی در برابر کارت‌کاتالوگ
چپ: یک نفر تمام راهرو را می‌گردد. راست: کارت‌کاتالوگ شماره قفسه را می‌دهد. Index همان کاتالوگ است، نه خودِ کتاب‌ها.

کوئری کند، و نجاتش

جدول orders را تصور کن. «سفارش‌های کاربر ۸۱۲۳» بدون فهرست یعنی خواندن همه سطرها. یک Index روی user_id همان کارت‌کاتالوگ است. اگر معمولاً «سفارش‌های اخیر همان کاربر» را می‌خواهی، فهرست مرکب دقیق‌تر است.

-- کوئری کند: Full Table Scan
SELECT * FROM orders WHERE user_id = 8123;

-- نجات:
CREATE INDEX idx_orders_user ON orders (user_id);

-- کوئری مرکب رایج: سفارش‌های اخیر یک کاربر
CREATE INDEX idx_user_created ON orders (user_id, created_at DESC);

قواعدی که هزینه را نشان می‌دهند

Index رایگان نیست. هر کدام یک وام است که با هر نوشتن قسطش را می‌دهی. جدول write-heavy با ده فهرست = کتابفروشی‌ای که هر کتاب تازه را در ده کاتالوگ جدا هم ثبت می‌کند.

  • Index مرکب (a, b) به کوئری روی a و روی (a,b) کمک می‌کند، ولی به کوئری فقط روی b نه — ترتیب ستون‌ها مهم است: قانون چپ‌ترین پیشوند.
  • هر Index نوشتن را کند می‌کند: INSERT و UPDATE باید همه درخت‌ها را هم به‌روز کنند.
  • Covering Index: اگر همه ستون‌های موردنیاز کوئری داخل Index باشد، اصلاً به جدول — همان قفسه — مراجعه نمی‌شود.
  • اول با EXPLAIN ببین دیتابیس واقعاً چه می‌کند؛ حدس نزن. Query Plan شغلش نشان دادن همین مسیر است.

سه جور فهرست، سه شغل

همه Index ها یک شکل نیستند. شغل را بفهم، بعد ساختار را انتخاب کن.

B-Tree
درخت متوازن روی دیسک. شغلش تساوی، بازه — بزرگ‌تر و کوچک‌تر — و ORDER BY است. پیش‌فرض تقریباً همه‌جا.
Hash Index
فقط تساوی، ولی سریع‌تر. اساس Key-Value ها: کلید را می‌دهی، جعبه را برمی‌داری؛ بازه بلد نیست.
Inverted Index
از کلمه به سندهای حاوی آن. قلب موتور جستجو — Elasticsearch. «تهران» را می‌پرسی، لیست سند می‌گیری، نه اینکه همه کتاب را بخوانی.

به زبان ساده

Index کارت‌کاتالوگ کتابفروشی است: به‌جای گشتن همه قفسه‌ها، مستقیم سراغ محل جواب می‌روی.

مثال واقعی

برای سفارش‌های یک کاربر در جدول صد میلیونی، Index روی user_id از Full Table Scan جلوگیری می‌کند.

دانش‌سنجی

آزمون درس

۴ Q
01
Index مرکب (user_id, created_at) به کدام کوئری کمک نمی‌کند؟
02
هزینه پنهان هر Index چیست؟
03
قلب موتور جستجوی متنی کدام ساختار است؟
04
اولین ابزار تشخیص کوئری کند؟