راهنمای DMVهای پیشنهاد ایندکس‌های مفقود در SQL Server

تعریف مجموعه و مدل تصمیم‌گیری

این مجموعه در خانواده بصری «Performance / Tuning / Optimization» قرار می‌گیرد، زیرا اعضای آن داده یا فرمانی برای تحلیل Performance تولید می‌کنند. مدل پیشنهادی چهار گام دارد: Scope را محدود کنید، Snapshot بگیرید، سیگنال را با منبع دوم هم‌بسته سازید و فقط سپس اقدام قابل بازگشت تعریف نمایید. در Runbook خانواده 15، تفسیر این بند به شواهد اختصاصی Missing Index DMVs وابسته است.

در خانواده 15، هر عضو باید نقش متفاوتی داشته باشد. یکی Baseline می‌سازد، دیگری جزئیات ساختاری یا عملیاتی می‌دهد و عضو بعدی نتیجه را به تصمیم نگهداری نزدیک می‌کند. اگر دو ابزار پاسخ یکسان می‌دهند، Query اضافی حذف و ابزار کم‌هزینه‌تر انتخاب می‌شود.

این تصویر، جایگاه Missing Index DMVs را با تمرکز بر SYS_DM_DB_MISSING_INDEX_DETAILS، SYS_DM_DB_MISSING_INDEX_GROUPS و SYS_DM_DB_MISSING_INDEX_GROUP_STATS نشان می‌دهد؛ پنل عددی پایین شکل برای جداکردن مشاهده خام از تصمیم اجرایی طراحی شده است.

دسته‌بندی اعضا و مسیر مطالعه

جدول مقایسه تصمیم‌محور اعضای مجموعه

ارتباط داده‌ها از Baseline تا اقدام

برای این مجموعه، Snapshotها باید با یک Capture ID مشترک ذخیره شوند. نام دیتابیس، زمان محلی و UTC، نسخه SQL Server، وضعیت سرویس و Scope Query کنار خروجی قرار می‌گیرد تا مقایسه میان sys.dm_db_missing_index_details و sys.dm_db_missing_index_columns از نظر زمانی معتبر باشد.

مرحله بعد تبدیل سیگنال به فرضیه است. برای نمونه، عدد بزرگ فقط می‌گوید کجا نگاه کنیم؛ علت با Plan، Query Text، نوع Storage، تغییرات داده یا تنظیم Maintenance روشن می‌شود. این تفکیک مانع آن است که ابزار مشاهده به ماشین تولید تغییرات خودکار تبدیل شود. کاربرد این اصل در Missing Index DMVs با معیارهای ویژه مجموعه 15 سنجیده می‌شود.

در نمودار دوم، مسیر SYS_DM_DB_MISSING_INDEX_DETAILS تا SYS_DM_DB_MISSING_INDEX_GROUP_STATS_QUERY به‌صورت مرحله‌ای ترسیم شده تا ورودی، تبدیل و خروجی Missing Index DMVs در یک نگاه قابل دنبال‌کردن باشد.

شش مثال ترکیبی و مستقل برای خانواده

مثال ترکیبی 1: ساخت نمای پایه برای خانواده ابزارها

این مثال ترکیبی از اعضای خانواده «راهنمای DMVهای پیشنهاد ایندکس‌های مفقود در SQL Server» استفاده می‌کند تا یک سؤال سطح‌بالا را بدون کپی‌کردن مثال‌های مقاله‌های فرزند پاسخ دهد.

SELECT mid.statement,mid.equality_columns,mid.inequality_columns,mid.included_columns
FROM sys.dm_db_missing_index_details AS mid WHERE mid.database_id=DB_ID();

نکته این سناریو، ترکیب کنترل‌شده منابع خانواده 15 است؛ نتیجه باید قبل از هر تغییر با Workload و Plan واقعی تطبیق داده شود.

مثال ترکیبی 2: محدودکردن تحلیل به موارد قابل اقدام

این مثال ترکیبی از اعضای خانواده «راهنمای DMVهای پیشنهاد ایندکس‌های مفقود در SQL Server» استفاده می‌کند تا یک سؤال سطح‌بالا را بدون کپی‌کردن مثال‌های مقاله‌های فرزند پاسخ دهد. در مجموعه 15، این تصمیم برای Missing Index DMVs باید جدا از خانواده‌های دیگر ثبت شود.

SELECT TOP(20) mid.statement,migs.user_seeks,migs.avg_user_impact,
       migs.avg_total_user_cost*migs.avg_user_impact*(migs.user_seeks+migs.user_scans) AS improvement_score
FROM sys.dm_db_missing_index_group_stats AS migs
JOIN sys.dm_db_missing_index_groups AS mig ON mig.index_group_handle=migs.group_handle
JOIN sys.dm_db_missing_index_details AS mid ON mid.index_handle=mig.index_handle
WHERE mid.database_id=DB_ID() ORDER BY improvement_score DESC;

نکته این سناریو، ترکیب کنترل‌شده منابع خانواده 15 است؛ نتیجه باید قبل از هر تغییر با Workload و Plan واقعی تطبیق داده شود. برای Missing Index DMVs، اجرای این توصیه در خانواده 15 نیازمند Baseline مخصوص همان موضوع است.

مثال ترکیبی 3: اتصال دو منبع برای ایجاد Context

این مثال ترکیبی از اعضای خانواده «راهنمای DMVهای پیشنهاد ایندکس‌های مفقود در SQL Server» استفاده می‌کند تا یک سؤال سطح‌بالا را بدون کپی‌کردن مثال‌های مقاله‌های فرزند پاسخ دهد. این نکته در تحلیل خانواده 15 با محور Missing Index DMVs به‌صورت مستقل ارزیابی می‌شود.

SELECT mig.index_group_handle,mig.index_handle,mid.statement
FROM sys.dm_db_missing_index_groups AS mig
JOIN sys.dm_db_missing_index_details AS mid ON mid.index_handle=mig.index_handle
WHERE mid.database_id=DB_ID();

نکته این سناریو، ترکیب کنترل‌شده منابع خانواده 15 است؛ نتیجه باید قبل از هر تغییر با Workload و Plan واقعی تطبیق داده شود. برای موضوع Missing Index DMVs در مجموعه 15، همین قاعده باید با داده همان Scope تطبیق داده شود.

مثال ترکیبی 4: تبدیل Metadata به گزارش تصمیم

این مثال ترکیبی از اعضای خانواده «راهنمای DMVهای پیشنهاد ایندکس‌های مفقود در SQL Server» استفاده می‌کند تا یک سؤال سطح‌بالا را بدون کپی‌کردن مثال‌های مقاله‌های فرزند پاسخ دهد. در Runbook خانواده 15، تفسیر این بند به شواهد اختصاصی Missing Index DMVs وابسته است.

SELECT mid.statement,mic.column_name,mic.column_usage
FROM sys.dm_db_missing_index_details AS mid
CROSS APPLY sys.dm_db_missing_index_columns(mid.index_handle) AS mic
WHERE mid.database_id=DB_ID() ORDER BY mid.index_handle,mic.column_id;

نکته این سناریو، ترکیب کنترل‌شده منابع خانواده 15 است؛ نتیجه باید قبل از هر تغییر با Workload و Plan واقعی تطبیق داده شود. کاربرد این اصل در Missing Index DMVs با معیارهای ویژه مجموعه 15 سنجیده می‌شود.

مثال ترکیبی 5: بررسی سناریوی نسخه یا قابلیت خاص

این مثال ترکیبی از اعضای خانواده «راهنمای DMVهای پیشنهاد ایندکس‌های مفقود در SQL Server» استفاده می‌کند تا یک سؤال سطح‌بالا را بدون کپی‌کردن مثال‌های مقاله‌های فرزند پاسخ دهد. در مجموعه 15، این تصمیم برای Missing Index DMVs باید جدا از خانواده‌های دیگر ثبت شود.

SELECT TOP(10) misq.group_handle,misq.query_hash,misq.query_plan_hash,misq.user_seeks,misq.avg_user_impact
FROM sys.dm_db_missing_index_group_stats_query AS misq
ORDER BY misq.avg_total_user_cost*misq.avg_user_impact*(misq.user_seeks+misq.user_scans) DESC;

نکته این سناریو، ترکیب کنترل‌شده منابع خانواده 15 است؛ نتیجه باید قبل از هر تغییر با Workload و Plan واقعی تطبیق داده شود. برای Missing Index DMVs، اجرای این توصیه در خانواده 15 نیازمند Baseline مخصوص همان موضوع است.

مثال ترکیبی 6: تهیه خروجی نهایی برای Runbook

این مثال ترکیبی از اعضای خانواده «راهنمای DMVهای پیشنهاد ایندکس‌های مفقود در SQL Server» استفاده می‌کند تا یک سؤال سطح‌بالا را بدون کپی‌کردن مثال‌های مقاله‌های فرزند پاسخ دهد. این نکته در تحلیل خانواده 15 با محور Missing Index DMVs به‌صورت مستقل ارزیابی می‌شود.

WITH Suggestions AS
(SELECT mid.statement,mid.equality_columns,mid.inequality_columns,mid.included_columns,
        ROW_NUMBER() OVER(PARTITION BY mid.statement,mid.equality_columns,mid.inequality_columns,mid.included_columns ORDER BY mid.index_handle) AS rn
 FROM sys.dm_db_missing_index_details AS mid WHERE mid.database_id=DB_ID())
SELECT * FROM Suggestions WHERE rn=1;

نکته این سناریو، ترکیب کنترل‌شده منابع خانواده 15 است؛ نتیجه باید قبل از هر تغییر با Workload و Plan واقعی تطبیق داده شود. برای موضوع Missing Index DMVs در مجموعه 15، همین قاعده باید با داده همان Scope تطبیق داده شود.

سناریوهای واقعی استفاده

در Incident، ابتدا ارزان‌ترین عضو خانواده 15 برای محدودکردن دامنه اجرا می‌شود. اگر سیگنال پایدار بود، ابزار جزئیات روی همان Object فراخوانی و خروجی با Query Store یا Plan متناظر می‌شود. این مسیر زمان جمع‌آوری را کوتاه و بار تشخیص را کنترل می‌کند.

در Capacity Planning، Snapshotهای هفتگی از معیارهای اصلی نگهداری و با Deploymentها علامت‌گذاری می‌شوند. تغییر روند پس از Release مهم‌تر از یک عدد مطلق است و کمک می‌کند بودجه سخت‌افزار یا بازطراحی قبل از اشباع واقعی برنامه‌ریزی گردد. در Runbook خانواده 15، تفسیر این بند به شواهد اختصاصی Missing Index DMVs وابسته است.

در آموزش تیم، هر عضو به یک سؤال مشخص متصل می‌شود. فراگیر باید توضیح دهد چه چیزی را مشاهده کرده، چه چیزی را هنوز نمی‌داند و کدام منبع دوم برای رد یا تأیید فرضیه لازم است؛ این تمرین از حفظ Syntax مفیدتر است. کاربرد این اصل در Missing Index DMVs با معیارهای ویژه مجموعه 15 سنجیده می‌شود.

اشتباهات رایج در استفاده ترکیبی

• ترکیب داده‌های قبل و بعد از Restart بدون ثبت مرز Reset؛ اصلاح: زمان شروع موتور و Capture ID ذخیره شود.
• مقایسه دیتابیس‌های با حجم و Workload متفاوت با Threshold یکسان؛ اصلاح: Baseline محلی و واحد مشترک تعریف گردد.
• اجرای ابزار عمیق روی همه اشیا؛ اصلاح: ابتدا با Query سبک فهرست کوتاه ساخته شود.
• کپی‌کردن Recommendation به DDL؛ اصلاح: هم‌پوشانی، هزینه نگهداری و Plan در محیط آزمایش سنجیده شود.
• نداشتن مالک و تاریخ بازبینی؛ اصلاح: هر Finding به Ticket، مسئول و معیار بسته‌شدن متصل گردد.

Performance مجموعه و هزینه جمع‌آوری

خود فرآیند مانیتورینگ باید Budget داشته باشد. در خانواده 15 Queryهای Catalog و DMV با Top، Predicate و Projection محدود اجرا می‌شوند؛ فرمان‌های اسکن یا Update نیز در پنجره جدا و با اندازه‌گیری Reads، CPU و مدت اجرا قرار می‌گیرند.

تعداد Snapshot بیشتر لزوماً دید بهتر ایجاد نمی‌کند. تناوب باید با سرعت تغییر سیگنال هماهنگ باشد: شمارنده سریع ممکن است هر چند دقیقه، Metadata پایدار روزانه و اسکن فیزیکی فقط پس از عبور از شرط اندازه یا رخداد نگهداری جمع‌آوری شود. در مجموعه 15، این تصمیم برای Missing Index DMVs باید جدا از خانواده‌های دیگر ثبت شود.

برای گزارش، داده خام کوتاه‌مدت و Aggregation بلندمدت جدا نگهداری شود. Retention نامحدود، Indexهای مخزن مانیتورینگ و گزارش‌های Sort سنگین می‌توانند هزینه‌ای بیشتر از سود تشخیص ایجاد کنند. برای Missing Index DMVs، اجرای این توصیه در خانواده 15 نیازمند Baseline مخصوص همان موضوع است.

Best Practices برای پیاده‌سازی سازمانی

• هر Query را به یک سؤال عملی و یک مالک متصل کنید.
• Capture ID و Timestamp مشترک برای همه منابع یک تحلیل بسازید.
• نسخه SQL Server و مجوزهای لازم را در ابتدای Runbook ثبت نمایید.
• مرحله مشاهده را از مرحله تغییر جدا و Approval مستقل تعریف کنید.
• معیار قبل/بعد، زمان انتظار مشاهده اثر و Rollback را پیش از اجرا بنویسید.
• پس از هر Incident، Queryها و Thresholdها را با شواهد جدید بازبینی کنید.

نمای سوم، رابطه SYS_DM_DB_MISSING_INDEX_GROUPS، SYS_DM_DB_MISSING_INDEX_COLUMNS و Missing Index DMVs را در کنار شاخص‌های تصمیم نمایش می‌دهد و مشخص می‌کند کدام مسیر برای Performance یا رفع خطا اولویت دارد.

مزایا، محدودیت‌ها و مرز استفاده

مزیت این خانواده، پوشش چند زاویه از مسئله تبدیل سیگنال‌های موقت Missing Index به پیشنهادهای قابل آزمایش، ادغام‌شده و کم‌ریسک برای Workload واقعی. است. کنارهم‌گذاشتن اعضا امکان می‌دهد نتیجه یک ابزار با ابزار دیگر کنترل شود و تصمیم از حالت تک‌منبعی خارج گردد.

محدودیت مهم، ناهمگونی زمان و ماندگاری داده‌هاست. برخی شمارنده‌ها با Restart صفر می‌شوند، بعضی خروجی لحظه‌ای‌اند و فرمان‌های Statistics یا DBCC اثر اجرایی دارند. گزارش بدون Timestamp و Context از نظر تحلیلی ناقص است. این نکته در تحلیل خانواده 15 با محور Missing Index DMVs به‌صورت مستقل ارزیابی می‌شود.

این مجموعه برای اجرای کور در Incident، ساخت خودکار ایندکس یا تغییر سراسری تنظیمات مناسب نیست. وقتی Baseline ندارید، نخست باید مشاهده کم‌خطر و ثبت شواهد را انجام دهید و تغییر را به مرحله بعد منتقل کنید. برای موضوع Missing Index DMVs در مجموعه 15، همین قاعده باید با داده همان Scope تطبیق داده شود.

سؤالات متداول مجموعه

از میان اعضای Missing Index DMVs از کدام مورد شروع کنیم؟

شروع به مسئله بستگی دارد. برای Baseline نخست «sys.dm_db_missing_index_details» و برای تکمیل Context سپس «sys.dm_db_missing_index_groups» را بخوانید؛ مقاله مادر ترتیب مفهومی را می‌دهد اما انتخاب عملی باید از سؤال Workload آغاز شود.

آیا اجرای همه ابزارهای خانواده 15 در یک Job مناسب است؟

خیر، هزینه و Scope اعضا متفاوت است. DMV سبک را می‌توان با تناوب بیشتر ثبت کرد، ولی فرمان یا اسکن پرهزینه باید پنجره جدا، فیلتر هدفمند و شرط توقف داشته باشد. در Runbook خانواده 15، تفسیر این بند به شواهد اختصاصی Missing Index DMVs وابسته است.

برای پروژه کوچک چند عضو این مجموعه کافی است؟

معمولاً یک ابزار Baseline، یک ابزار جزئیات و یک معیار اعتبارسنجی کافی است. در این خانواده می‌توان sys.dm_db_missing_index_details را با sys.dm_db_missing_index_columns ترکیب کرد و با رشد سیستم پوشش را توسعه داد.

خروجی این خانواده چگونه در گزارش مدیریتی استفاده شود؟

اعداد خام به زبان ریسک و اقدام تبدیل می‌شوند: شیء متاثر، شدت، زمان مشاهده، مالک، پیشنهاد آزمایش و معیار موفقیت. گزارش مدیریتی نباید ستون‌های فنی را بدون تفسیر نمایش دهد. کاربرد این اصل در Missing Index DMVs با معیارهای ویژه مجموعه 15 سنجیده می‌شود.

تفاوت مقاله مادر با مقاله‌های فرزند چیست؟

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

چه زمانی مشاوره تخصصی برای این مجموعه منطقی است؟

وقتی تحلیل به تغییر ایندکس، تنظیم Statistics، DDL یا عملیات گسترده منتهی می‌شود، بازبینی یک متخصص SQL Server می‌تواند ریسک Regression را کم کند. تهیه Snapshotهای این راهنما جلسه مشاوره را عملی و قابل اندازه‌گیری می‌سازد. برای Missing Index DMVs، اجرای این توصیه در خانواده 15 نیازمند Baseline مخصوص همان موضوع است.

خطای رایج در ترکیب اعضای Missing Index DMVs چیست؟

رایج‌ترین خطا، کنارهم‌گذاشتن Snapshotهایی با زمان و Scope متفاوت است. همه منابع باید Timestamp مشترک یا بازه قابل تطبیق داشته باشند و Reset شدن شمارنده‌ها ثبت شود. این نکته در تحلیل خانواده 15 با محور Missing Index DMVs به‌صورت مستقل ارزیابی می‌شود.

چگونه هزینه Performance گزارش جامع را کنترل کنیم؟

Queryها را مرحله‌ای اجرا کنید، ابتدا Top و فیلتر اندازه بگذارید، سپس فقط برای موارد مشکوک وارد اسکن عمیق شوید. ذخیره خروجی کوچک و تحلیل Offline معمولاً از تکرار Query سنگین بهتر است. برای موضوع Missing Index DMVs در مجموعه 15، همین قاعده باید با داده همان Scope تطبیق داده شود.

بهترین Practice برای تبدیل خروجی خانواده به اقدام چیست؟

هر اقدام باید یک فرضیه، شواهد از حداقل دو عضو، معیار قبل/بعد، مالک و Rollback داشته باشد. بدون این پنج جزء، خروجی در حد Recommendation غیرقطعی باقی می‌ماند. در Runbook خانواده 15، تفسیر این بند به شواهد اختصاصی Missing Index DMVs وابسته است.

سازگاری نسخه‌ای اعضای خانواده چگونه کنترل شود؟

وجود DMV یا Option، نام مجوز و ستون‌های قابل اتکا را با نسخه هدف بررسی کنید. Script باید نسخه را ثبت و برای قابلیت‌های جدید مسیر جایگزین یا پیام روشن داشته باشد. کاربرد این اصل در Missing Index DMVs با معیارهای ویژه مجموعه 15 سنجیده می‌شود.

سؤالات مصاحبه برای نقش DBA و Performance Engineer

چگونه ابزار نخست خانواده را انتخاب می‌کنید؟

ابزار نخست باید کم‌هزینه‌ترین منبعی باشد که Scope مسئله را محدود می‌کند؛ سپس فقط برای موارد منتخب سراغ جزئیات یا فرمان سنگین می‌روم. این پاسخ در خانواده 15 باید با یکی از اعضای واقعی مجموعه مثال زده شود.

چرا Timestamp مشترک مهم است؟

زیرا هم‌بستگی دو منبع با زمان متفاوت می‌تواند علت و معلول ساختگی ایجاد کند. Capture ID مشترک مرز تحلیل را حفظ می‌کند. این پاسخ در خانواده 15 باید با یکی از اعضای واقعی مجموعه مثال زده شود.

چه زمانی یک Finding به اقدام تبدیل می‌شود؟

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

چگونه Threshold تعیین می‌کنید؟

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

چرا خودکارسازی کامل خطرناک است؟

زیرا بسیاری از خروجی‌ها پیشنهاد یا Snapshot موقت‌اند و Context طراحی، Constraint، هزینه نوشتن و فصل کاری را نمی‌بینند. این پاسخ در خانواده 15 باید با یکی از اعضای واقعی مجموعه مثال زده شود.

پس از تغییر چه چیزی را ثبت می‌کنید؟

زمان اجرا، Script دقیق، Metricهای قبل/بعد، Planهای متاثر و تصمیم نگهداری یا بازگشت را در Ticket و مخزن فنی ذخیره می‌کنم. این پاسخ در خانواده 15 باید با یکی از اعضای واقعی مجموعه مثال زده شود.

چک‌لیست نهایی خانواده

1. تعداد و نام اعضای همین مجموعه را با ورودی کنترل کنید.
2. برای هر عضو نقش Baseline، جزئیات، اعتبارسنجی یا اقدام را تعیین نمایید.
3. Slug و لینک همه صفحات فرزند را پیش از انتشار آزمایش کنید.
4. Capture ID، Timestamp و نسخه SQL Server را در خروجی‌ها نگه دارید.
5. Queryهای عمیق را فقط روی فهرست کوتاه و در زمان کنترل‌شده اجرا کنید.
6. هر Recommendation را با Plan و هزینه نگهداری اعتبارسنجی نمایید.
7. تغییر Production را با Approval، Backup و Rollback اجرا کنید.
8. اثر تغییر را با همان معیارهای Baseline دوباره بسنجید.