طراحی و پیاده سازی

Database Index چیست و چگونه سرعت Query را افزایش می‌دهد؟

انتهای هر کتاب خوب، فهرست موضوعی وجود دارد؛ صفحه‌ای که به‌جای ورق زدن کل کتاب، مستقیم به صفحه درست می‌رساند. پایگاه داده دقیقاً با همان مشکل کتابِ بدون فهرست دست‌به‌گریبان است و راه‌حلش هم نامی همانند دارد: شاخص یا Database Index. این مقاله با مثال جدول کاربران یک سامانه پیش می‌رود تا روشن شود شاخص چگونه پرس‌وجو (Query) را سریع می‌کند و در عوض چه چیزی از شما می‌گیرد.

مفهوم: پرس‌وجو بدون شاخص چگونه کار می‌کند

وقتی درخواستی به پایگاه داده می‌رسد که می‌گوید «کاربرانی را با این شرط پیدا کن»، اگر ساختار پشتیبانی وجود نداشته باشد، تنها راه، پیمایش کامل جدول (Full Table Scan) است: تک‌به‌تک گذر از همه سطرها و بررسی شرط. در جدولی چند صد سطری، این کار در زمانی ناچیز تمام می‌شود. اما در جدولی که با رشد محصول پر می‌شود، هر پرس‌وجوی این‌چنینی باید حجم فزاینده داده را از اول تا آخر بگردد؛ هزینه‌ای که با هر رکورد تازه سنگین‌تر می‌شود و کاربر آن را به شکل صفحه‌های کند حس می‌کند.

بدتر اینکه این هزینه روی هم انباشته می‌شود: ده کاربر هم‌زمان با ده پیمایش کامل مواجه‌اند و اگر هر پرس‌وجو بخشی از ظرفیت را بگیرد، کندی فقط به صفحه خودش محدود نمی‌ماند و به کل سیستم سرریز می‌کند.

شاخص چگونه این پیمایش را حذف می‌کند

شاخص، ساختاری جدا از جدول اما هم‌گام با آن است: ستون یا ستون‌های منتخب را به‌صورت مرتب نگه می‌دارد و کنار هر مقدار، اشاره‌گری به سطر اصلی می‌گذارد. چون داده مرتب است، جست‌وجو دیگر از ابتدا تا انتها نیست؛ مثل فهرست تلفنی که با دانستن حرف اول نام، مستقیم به محدوده درست می‌روید. ساختار رایج برای این منظور درختی و متوازن است (معروف به B-Tree) و ویژگی مهمش این است که تعداد گام‌های رسیدن به مقدار با رشد حجم داده، به‌کندی و به‌صورت لگاریتمی زیاد می‌شود؛ یعنی چندبرابر شدن داده، فقط چند گام اضافه می‌کند، نه چندبرابر گام.

یک ظرافت مهم: شاخص خودش زنده است. هر درج، ویرایش یا حذف در جدول، ساختار شاخص‌های مرتبط را هم تغییر می‌دهد تا ترتیب حفظ شود؛ همین نکته، ریشه هزینه‌های بخش بعدی است.

مثال مفهومی: جدول کاربران یک سامانه

فرض کنید سامانه‌ای مدیریت ارتباط با مشتریان دارد و جدول کاربرانش ستون‌هایی مثل شناسه، نام، ایمیل، شهر و تاریخ عضویت دارد. صفحه ورود با ایمیل کار می‌کند؛ بدون شاخص، هر ورود یعنی پیمایش کل جدول کاربران. شاخص روی ستون ایمیل، این پیمایش را به چند گام در ساختار مرتب تبدیل می‌کند و سرعت ورود دیگر به اندازه جدول گره نمی‌خورد.

حالا بخش گزارش می‌خواهد کاربران عضوشده در یک بازه زمانی مشخص از هر شهر را ببیند. شاخص ترکیبی (Composite Index) روی دو ستون شهر و تاریخ عضویت، این ترکیب را پوشش می‌دهد؛ به شرط آنکه ترتیب ستون‌ها با الگوی پرس‌وجو هم‌خوان باشد: شرط برابری نخست بیاید و بازه بعد. ترتیب برعکس، فقط نیمی از ارزش شاخص را آزاد می‌کند.

نکته سوم، انتخاب‌پذیری (Selectivity) است: ستونی که مقادیر بسیار کم‌تنوع دارد، مثل وضعیت فعال بودن با فقط دو مقدار، شاخصی کم‌اثر می‌سازد؛ چون جست‌وجو عملاً به بخش بزرگی از جدول اشاره می‌کند و پیمایش را حذف نمی‌کند. در چنین ستونی، ساخت شاخص بیشتر شبیه ساختن فهرستی است که به نیمی از کتاب اشاره می‌کند.

مزایا و هزینه‌ها در یک نگاه

شاخص ابزار رایگان نیست؛ هر شاخص دو صورت‌حساب دارد، یکی در زمان خواندن و یکی در زمان نوشتن. جدول زیر این مبادله را خلاصه می‌کند.

جنبهمزیتهزینه و محدودیت
خواندن دادهپیمایش کامل جدول حذف می‌شود و جست‌وجو به چند گام در ساختار مرتب تبدیل می‌شودفقط وقتی الگوی پرس‌وجو با ساختار شاخص هم‌خوان باشد اثر می‌کند
نوشتن داده—هر درج، ویرایش و حذف باید شاخص‌های مرتبط را هم به‌روز کند و کندتر می‌شود
فضای ذخیره‌سازی—هر شاخص ساختاری فرعی است که فضا می‌گیرد و نگهداری می‌خواهد
مرتب‌سازی و بازهترتیب از پیش آماده است و پرس‌وجوهای بازه‌ای و مرتب‌شده ارزان‌تر می‌شوندترتیب ستون‌ها در شاخص ترکیبی باید دقیق با الگوی پرس‌وجو هم‌خوان باشد
یکتایی دادهشاخص یکتا جلوی ثبت رکورد تکراری را می‌گیردقید یکتا خودش هزینه بررسی در هر نوشتن دارد

چه زمانی ایجاد شاخص تصمیم درستی است؟

شاخص ابزار پاسخ به پرس‌وجوهای واقعی است، نه پیش‌بینی‌های فرضی. سیاست سالم این است: از پرس‌وجوهای کند و پرتکرار شروع کنید؛ ستون‌های شرط، اتصال و مرتب‌سازی آن‌ها را شناسایی کنید؛ انتخاب‌پذیری‌شان را بسنجید و سپس شاخص بسازید. اگر بخشی از سیستم با الگوی خواندن سنگین و نوشتن سبک کار می‌کند، دامنه انتخاب شاخص‌ها بازتر می‌شود؛ جایی که نوشتن سنگین است، هر شاخص اضافه باری است که به هر ثبت سفارش یا ثبت گزارش اضافه می‌شود.

خطاهای رایج

  • شاخص برای هر ستون؛ هزینه نوشتن و فضای ذخیره‌سازی بی‌دلیل بالا می‌رود و انتخاب میان گزینه‌های زیاد، تصمیم‌گیری موتور پایگاه داده را هم پیچیده‌تر می‌کند.
  • ترتیب اشتباه ستون‌ها در شاخص ترکیبی؛ شاخصی که ساخته می‌شود اما الگوی پرس‌وجو از مسیرش عبور نمی‌کند.
  • شاخص روی ستون کم‌تنوع؛ ساخت و نگهداری می‌شود، اما صرفه‌جویی چشمگیری نمی‌سازد.
  • به‌کارگیری عملکرد روی ستون شرط به‌شکلی که شاخص بی‌اثر شود؛ وقتی مقدار ستون پیش از مقایسه تغییر شکل داده شود، پیمایش کامل جدول دوباره برمی‌گردد.
  • ساختن و تمام‌کردن کار؛ شاخص بخشی از زنده بودن سیستم است و با تغییر الگوی پرس‌وجو باید دوره‌ای بازبینی شود.

کاربرد عملی: مسیر کوتاه از کندی تا شاخص

در پروژه واقعی، نقطه شروع معمولاً یک شکایت ملموس است: صفحه‌ای کند، گزارشی سنگین یا نقطه اتصالی که در اوج ترافیک نفس نمی‌کشد. قدم‌ها معمولاً این‌گونه‌اند: الگوی پرس‌وجوی مسئله‌دار را دقیق بفهمید؛ طرح اجرا (Execution Plan) را بررسی کنید تا معلوم شود پیمایش کامل در کار است یا ساختار پشتیبان؛ شاخص را بر اساس همان الگو بسازید؛ دوباره اندازه بگیرید و اگر بهبود واقعی بود، مستندش کنید. سپس یک بازه منظم برای مرور شاخص‌ها بگذارید؛ شاخصی که دیگر استفاده نمی‌شود، باری است که فقط هزینه دارد.

یک یادآوری برای گفت‌وگو با تیم محصول: شاخص روی داده امروز تصمیم می‌گیرد و روی الگوی مصرف فردا اثر می‌گذارد. وقتی قابلیت تازه‌ای رفتار جست‌وجو یا گزارش را تغییر می‌دهد، مرور شاخص‌ها باید بخشی از تعریف آماده‌به‌کار همان قابلیت باشد، نه کاری که بعداً «اگر شد» انجام می‌شود.

نکات کلیدی این مقاله

  • شاخص ساختاری مرتب و هم‌گام با جدول است که پیمایش کامل را به چند گام جست‌وجو تبدیل می‌کند.
  • هر شاخص دو صورت‌حساب دارد: سرعت خواندن در برابر هزینه نوشتن و فضای ذخیره‌سازی.
  • ترتیب ستون‌ها در شاخص ترکیبی باید با الگوی شرط و بازه پرس‌وجو هم‌خوان باشد.
  • ستون کم‌تنوع شاخص کم‌اثر می‌سازد؛ انتخاب‌پذیری را پیش از ساختن بسنجید.
  • شاخص برای الگوی دسترسی واقعی طراحی می‌شود، نه برای همه پرس‌وجوهای ممکن.

سوالات متداول

آیا شاخص همیشه سرعت را بالا می‌برد؟

برای خواندن، به شرط هم‌خوانی الگوی پرس‌وجو با ساختار شاخص، بله. اما برای نوشتن برعکس است؛ هر شاخص اضافه، هر ثبت و ویرایش را سنگین‌تر می‌کند. به همین دلیل شاخص را با دیدن پرس‌وجوهای واقعی اضافه می‌کنند، نه با انتظار کلی از سرعت.

چند شاخص برای یک جدول منطقی است؟

عدد ثابتی وجود ندارد. ملاک، ترکیب الگوهای خواندن و بار نوشتن همان جدول است؛ جدولی که مدام درج می‌شود باید محتاط‌تر باشد تا جدولی که بیشترش خوانده می‌شود. مرور دوره‌ای شاخص‌های بلااستفاده، بهتر از قاعده سرانگشتی است.

شاخص و کلید اصلی چه تفاوتی دارند؟

کلید اصلی یک قید یکتایی و هویت سطر است و در بیشتر پایگاه‌های داده خودش با یک شاخص پشتیبانی می‌شود؛ شاخص‌های جانبی اما ابزارهای اختیاری‌اند که برای ستون‌های دیگر ساخته می‌شوند تا الگوهای جست‌وجو و مرتب‌سازی پرتکرار را سریع کنند.

نوشته های مشابه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا