خانه/ ایندکس‌گذاری و کارایی/ نقشه اجرا

نقشه اجرا: نقشه‌ی راهی که موتور پایگاه‌داده واقعاً طی می‌کند

متوسط ۱۳ دقیقه مطالعه

در درس‌های قبل، چند بار عبارت‌هایی مثل SCAN و SEARCH ... USING INDEX دیدیم. این‌ها بخشی از نقشه اجرا (Execution Plan) هستند — گزارشی که نشان می‌دهد موتور پایگاه‌داده دقیقاً چطور قصد دارد (یا واقعاً) یک پرس‌وجو را اجرا کند: از کدام ایندکس استفاده می‌کند، جدول‌ها را به چه ترتیبی JOIN می‌کند، و کجاها هزینه‌بر است.

در SQL Server: نقشه‌ی گرافیکی

در SQL Server Management Studio (SSMS)، با فعال‌کردن «Include Actual Execution Plan» (یا کلید Ctrl+M)، بعد از اجرای پرس‌وجو یک نمودار گرافیکی با آیکون‌هایی مثل این‌ها می‌بینی:

Index Seek — دقیقاً معادل SEARCH ... USING INDEX در SQLite؛ جست‌وجوی مستقیم و سریع.
Index Scan / Table Scan — معادل SCAN؛ بررسی همه‌ی ردیف‌ها.
Key Lookup — همان قدم اضافه‌ای که در درس ایندکس غیرخوشه‌ای دیدیم (برگشت از ایندکس به جدول اصلی برای ستون‌های باقی‌مانده).
Nested Loop / Hash Match / Merge Join — سه روش مختلف اجرای JOIN که SQL Server بسته به اندازه‌ی جدول‌ها انتخاب می‌کند.

زیر هر آیکون، درصدی نشان داده می‌شود که هزینه‌ی نسبی آن مرحله را نسبت به کل پرس‌وجو نشان می‌دهد — جایی که این عدد بزرگ باشد، اولین جای مشکوک برای بهینه‌سازی است.

در SQLite: نسخه‌ی متنی همان ایده

Playground این سایت به‌جای نمودار گرافیکی، از EXPLAIN QUERY PLAN استفاده می‌کند — همان اطلاعات، فقط به‌صورت متنی. بیا این‌بار یک پرس‌وجوی واقعی‌تر با دو JOIN را بررسی کنیم:

امتحانش کن — نقشه‌ی اجرای یک JOIN، قبل از ایندکس

خط مربوط به جدول e (یعنی enrollments) را نگاه کن: SCAN e است — چون course_id در این جدول ایندکس ندارد، موتور مجبور است همه‌ی ردیف‌های enrollments را بررسی کند تا آن‌هایی با course_id = 1 را پیدا کند. حالا یک ایندکس اضافه می‌کنیم:

امتحانش کن — همان JOIN، بعد از ایندکس روی FK

حالا خط مربوط به e به SEARCH e USING INDEX idx_enroll_course (course_id=?) تبدیل شده. این دقیقاً همان تحلیلی است که در دنیای واقعی، وقتی یک پرس‌وجوی JOIN کند است، باید انجام بدهی: نقشه‌ی اجرا را باز کن، دنبال SCAN/Table Scan روی جدول‌های بزرگ بگرد، و ببین آیا ستون شرط JOIN یا WHERE، ایندکس دارد یا نه. نکته‌ی مهم: کلیدهای خارجی (Foreign Key) به‌طور خودکار ایندکس نمی‌گیرند — نه در SQLite و نه در SQL Server — این تصمیم همیشه با خودت است.

جمع‌بندی این درس

نقشه‌ی اجرا نشان می‌دهد موتور پایگاه‌داده واقعاً چطور یک پرس‌وجو را اجرا می‌کند — نه فقط چه چیزی برمی‌گرداند.
در SSMS به‌صورت گرافیکی (Index Seek/Scan، Key Lookup، Nested Loop/Hash Match) و در SQLite به‌صورت متنی با EXPLAIN QUERY PLAN دیده می‌شود.
ستون‌های استفاده‌شده در JOIN و WHERE — به‌خصوص کلیدهای خارجی — باید صراحتاً ایندکس بگیرند؛ خودکار نیست.
وقتی پرس‌وجویی کند است، اولین قدم تشخیص، خواندن دقیق نقشه‌ی اجرای آن است.

در آخرین درس این فصل، چند تکنیک عملی بهینه‌سازی پرس‌وجو را با تمرکز بر نوشتن شرط‌هایی که واقعاً از ایندکس استفاده می‌کنند (SARGable) می‌بینیم.