آموزش جامع sys.query_store_query_text در SQL Server؛ از ساختار تا تحلیل عملی
sys.query_store_query_text یکی از موضوعهای تخصصی خانواده Query Store است که برای متن پرسوجوهای ثبتشده در Query Store بهکار میرود. این مقاله از تعریف و ستونها آغاز میکند، رابطه آن را با سایر نماها توضیح میدهد و سپس ده مثال مستقل، خروجی نمونه، خطاهای رایج و نکات کارایی را ارائه میدهد.
نسخه و سازگاری: SQL Server 2016 و نسخههای بعدی. همه Queryها باید در همان پایگاه دادهای اجرا شوند که Query Store آن مورد بررسی است. برای بازگشت به نقشه کامل این مجموعه، راهنمای جامع نماهای کاتالوگ Query Store را مطالعه کنید.
sys.query_store_query_text چیست و چه اطلاعاتی میدهد؟
متن T-SQL، شناسه متن، هندل عبارت و وضعیت متن محدود یا رمزگذاریشده را نگهداری میکند. در عمل، این نما بخشی از زنجیرهای است که از متن Query شروع میشود، به هویت منطقی و طرح اجرایی میرسد و در نهایت آمار اجرا، انتظارها یا تنظیمات مدیریتی را قابل مشاهده میکند.
کاربرد محوری این مقاله، ردیابی متن دقیق یک گزارش کند و یافتن عبارتهایی که الگوی خاصی از نام جدول یا پارامتر را دارند. است. نتیجه مطلوب فقط نمایش چند ردیف نیست؛ هدف این است که مدیر پایگاه داده بتواند از داده کاتالوگی به یک فرضیه قابل آزمون و سپس یک اقدام کمریسک برسد.
نکته مهم: جستوجوی LIKE با الگوی آغازشونده با درصد روی متنهای فراوان میتواند پرهزینه باشد و متن ماژول رمزگذاریشده قابل بازیابی نیست.
ساختار، ستونهای کلیدی و ارتباطها
ستونهای مهم این نما عبارتاند از query_text_id، query_sql_text، statement_sql_handle، is_part_of_encrypted_module، has_restricted_text. همه ستونها در هر سناریو لازم نیستند؛ انتخاب باید بر اساس سؤال تحلیلی انجام شود.
- query_text_id: یکی از ستونهای کلیدی برای شناسایی، فیلتر، اتصال یا تفسیر خروجی.
- query_sql_text: یکی از ستونهای کلیدی برای شناسایی، فیلتر، اتصال یا تفسیر خروجی.
- statement_sql_handle: یکی از ستونهای کلیدی برای شناسایی، فیلتر، اتصال یا تفسیر خروجی.
- is_part_of_encrypted_module: یکی از ستونهای کلیدی برای شناسایی، فیلتر، اتصال یا تفسیر خروجی.
- has_restricted_text: یکی از ستونهای کلیدی برای شناسایی، فیلتر، اتصال یا تفسیر خروجی.
رابطه اصلی با سایر نماها چنین است: از طریق query_text_id به sys.query_store_query متصل میشود. این رابطه باید با کلیدهای رسمی برقرار شود تا ضرب ردیف، شمارش تکراری یا نسبتدادن اشتباه آمار رخ ندهد.
| بخش | نقش در تحلیل | نکته اجرایی |
|---|
| هویت | query_text_id | برای فیلتر و Join از کلید مناسب استفاده شود |
| مقدار اصلی | query_sql_text | فقط در صورت نیاز به لایه نمایش منتقل شود |
| ارتباط | از طریق query_text_id به sys.query_store_query متصل میشود. | Join صریح و قابل ممیزی نوشته شود |
| نسخه | SQL Server 2016 و نسخههای بعدی | پیش از اجرا سازگاری کنترل شود |
تصویر نخست، جایگاه sys.query_store_query_text، ستونهای محوری و مسیر ارتباط آن با تحلیل Query Store را نشان میدهد.
نحو پایه و پیشنیازهای دسترسی
این موضوع یک Catalog View است و مانند جدول با SELECT خوانده میشود. نام قابل استفاده در Queryهای این مقاله «sys.query_store_query_text» است.
SELECT TOP (20)
query_text_id,
query_sql_text
FROM sys.query_store_query_text
ORDER BY query_text_id DESC;
برای مشاهده دادههای Query Store معمولاً مجوزهای مشاهده وضعیت یا عملکرد پایگاه داده لازم است. سطح مجوز دقیق به نسخه SQL Server وابسته است؛ بنابراین اسکریپت تولیدی بهتر است با حساب کماختیار آزمایش و سپس حداقل مجوز لازم مستند شود.
ده مثال عملی و مستقل
مثال 1: نمایش نمونه ردیفها
در نخستین گام، ساختار واقعی sys.query_store_query_text را با تعداد محدودی ردیف مشاهده میکنیم تا نام ستونها و شکل داده روشن شود.
SELECT TOP (10) *
FROM sys.query_store_query_text
ORDER BY 1 DESC;
| خروجی نمونه | توضیح |
|---|
| ردیفهای بازگشتی | حداکثر ۱۰ |
| هدف | شناخت ساختار نما |
نکته کاربردی: در محیط عملی بهتر است بهجای ستاره فقط ستونهای لازم انتخاب شوند؛ این مثال عمداً برای شناسایی سریع ساختار نوشته شده است.
مثال 2: انتخاب ستونهای کلیدی query_text_id و query_sql_text
این نمونه فقط دو ستون محوری query_text_id و query_sql_text را میخواند تا نتیجه کوچک، قابل بررسی و مناسب ابزارهای مانیتورینگ باشد.
SELECT TOP (20)
query_text_id,
query_sql_text
FROM sys.query_store_query_text
ORDER BY query_text_id DESC;
| خروجی نمونه | توضیح |
|---|
| query_text_id | شناسه یا مقدار کلیدی |
| query_sql_text | ویژگی اصلی تحلیل |
نکته کاربردی: انتخاب ستون صریح هم خوانایی را بیشتر میکند و هم مانع انتقال دادههای سنگین یا غیرضروری میشود.
مثال 3: استفاده از فیلتر هدفمند
برای جلوگیری از اسکن بیدلیل، تحلیل را به مقدار مشخصی از query_text_id محدود میکنیم. مقدار نمونه را باید با مقدار موجود در پایگاه داده جایگزین کرد.
DECLARE @TargetId bigint = 1;
SELECT *
FROM sys.query_store_query_text
WHERE query_text_id = @TargetId;
| خروجی نمونه | توضیح |
|---|
| شرط | query_text_id = 1 |
| نتیجه | ردیف مرتبط در صورت وجود |
نکته کاربردی: در گزارشهای واقعی، شناسه هدف معمولاً از مرحله قبلی تحلیل Query Store یا از یک داشبورد انتخاب میشود.
تصویر دوم، جریان انتخاب داده، فیلتر، اتصال و تبدیل خروجی sys.query_store_query_text به گزارش فنی را نمایش میدهد.
مثال 4: اتصال به نمای مکمل
ارزش sys.query_store_query_text زمانی بیشتر میشود که کلیدهای آن با نمای مکمل Query Store متصل شوند. این Query رابطه اصلی مقاله را بهصورت عملی نشان میدهد.
SELECT TOP (25)
q.query_id,
qt.query_text_id,
qt.query_sql_text,
q.count_compiles
FROM sys.query_store_query_text AS qt
INNER JOIN sys.query_store_query AS q
ON q.query_text_id = qt.query_text_id
ORDER BY q.count_compiles DESC;
| خروجی نمونه | توضیح |
|---|
| نوع تحلیل | Join کاتالوگی |
| رابطه | از طریق query_text_id به sys.query_store_query متصل میشود. |
نکته کاربردی: Join باید روی کلید مستندشده انجام شود؛ اتصال بر اساس متن، زمان تقریبی یا ستونهای غیرکلیدی میتواند ردیفهای تکراری و نتیجه گمراهکننده بسازد.
مثال 5: مدیریت نتیجه خالی و NULL
برخی ستونها ممکن است NULL باشند یا نمای هدف هیچ ردیفی نداشته باشد. با COALESCE میتوان خروجی نمایشی کنترلشدهای برای گزارش ساخت.
SELECT TOP (20)
query_text_id,
COALESCE(CONVERT(nvarchar(4000), query_sql_text), N'بدون مقدار') AS safe_value
FROM sys.query_store_query_text
ORDER BY query_text_id DESC;
| خروجی نمونه | توضیح |
|---|
| query_text_id | نمونه شناسه |
| safe_value | مقدار واقعی یا «بدون مقدار» |
نکته کاربردی: COALESCE برای نمایش مناسب است؛ اما نباید نوع داده و معنای NULL را در منطق تحلیلی پنهان کند.
مثال 6: کنترل سازگاری نسخه پیش از اجرا
از آنجا که دسترسپذیری sys.query_store_query_text به نسخه SQL Server وابسته است، Query زیر پیش از خواندن نما وجود آن را بررسی میکند.
IF OBJECT_ID(N'sys.query_store_query_text', N'V') IS NULL
BEGIN
SELECT N'این نما در نسخه یا پیکربندی فعلی در دسترس نیست.' AS message;
END
ELSE
BEGIN
SELECT TOP (5) *
FROM sys.query_store_query_text;
END;
| خروجی نمونه | توضیح |
|---|
| حالت اول | نما موجود است و نمونه داده خوانده میشود |
| حالت دوم | پیام سازگاری بازگردانده میشود |
نکته کاربردی: این الگو برای اسکریپتهایی که روی چند نسخه اجرا میشوند ضروری است و از توقف کامل عملیات مانیتورینگ جلوگیری میکند.
مثال 7: سناریوی واقعی عیبیابی
ردیابی متن دقیق یک گزارش کند و یافتن عبارتهایی که الگوی خاصی از نام جدول یا پارامتر را دارند.
DECLARE @Pattern nvarchar(200) = N'%Orders%';
SELECT TOP (50)
query_text_id,
query_sql_text
FROM sys.query_store_query_text
WHERE query_sql_text LIKE @Pattern
ORDER BY query_text_id DESC;
| خروجی نمونه | توضیح |
|---|
| سناریو | ردیابی متن دقیق یک گزارش کند و یافتن عبارتهایی که الگوی خاصی از نام جدول یا پارامتر را دارند. |
| خروجی | فهرست اولویتدار برای اقدام |
نکته کاربردی: این خروجی نقطه شروع بررسی است؛ تصمیم نهایی باید با متن Query، طرح، آمار اجرا و شرایط محیط تولید تطبیق داده شود.
تصویر سوم، تفاوت خواندن گسترده با روش فیلترشده و قابل اتکا برای sys.query_store_query_text را مقایسه میکند.
مثال 8: روش اشتباه و نسخه اصلاحشده
خواندن بدون محدودیت تمام ستونها از sys.query_store_query_text در یک Job پرتکرار میتواند هزینه غیرضروری بسازد. نسخه اصلاحشده فقط ستون و ردیف لازم را دریافت میکند.
-- روش نامناسب برای اجرای پرتکرار
SELECT *
FROM sys.query_store_query_text;
-- نسخه کنترلشده
SELECT TOP (100)
query_text_id,
query_sql_text
FROM sys.query_store_query_text
WHERE query_text_id IS NOT NULL
ORDER BY query_text_id DESC;
| خروجی نمونه | توضیح |
|---|
| روش نامناسب | حجم خروجی نامحدود |
| روش اصلاحشده | ستون و تعداد ردیف کنترلشده |
نکته کاربردی: جستوجوی LIKE با الگوی آغازشونده با درصد روی متنهای فراوان میتواند پرهزینه باشد و متن ماژول رمزگذاریشده قابل بازیابی نیست.
مثال 9: الگوی مناسب برای داشبورد کارایی
برای داشبورد، ابتدا آخرین یا مهمترین ردیفها از sys.query_store_query_text انتخاب میشوند و تنها خروجی جمعوجور به لایه نمایش منتقل میشود.
DECLARE @RowLimit int = 50;
SELECT TOP (@RowLimit)
query_text_id,
query_sql_text
FROM sys.query_store_query_text
WHERE query_text_id IS NOT NULL
ORDER BY query_text_id DESC
OPTION (RECOMPILE);
| خروجی نمونه | توضیح |
|---|
| حد ردیف | ۵۰ |
| هدف | پاسخ سریع و قابل پیشبینی |
نکته کاربردی: ابتدا با شناسه، بازه زمانی یا آمار اجرا دامنه را محدود کنید و سپس متن کامل را بخوانید.
مثال 10: اعتبارسنجی خروجی برای اتوماسیون
آخرین مثال تعداد ردیفهای قابل استفاده را در یک متغیر میریزد تا Job یا ابزار مانیتورینگ بتواند وضعیت sys.query_store_query_text را بهصورت صریح گزارش کند.
DECLARE @AvailableRows bigint;
SELECT @AvailableRows = COUNT_BIG(*)
FROM sys.query_store_query_text;
SELECT
@AvailableRows AS available_rows,
CASE
WHEN @AvailableRows = 0 THEN N'دادهای ثبت نشده است'
ELSE N'داده برای تحلیل موجود است'
END AS status_message;
| خروجی نمونه | توضیح |
|---|
| available_rows | تعداد ردیف |
| status_message | پیام قابل استفاده در مانیتورینگ |
نکته کاربردی: در سامانه هشدار بهتر است وضعیت Query Store، زمان آخرین Capture و علت خالی بودن احتمالی نیز همراه این عدد ذخیره شود.
خطاهای رایج
- فرض اینکه هر ردیف sys.query_store_query_text بهتنهایی تصویر کامل عملکرد را نشان میدهد؛ در حالی که Join با لایههای مرتبط لازم است.
- جستوجوی LIKE با الگوی آغازشونده با درصد روی متنهای فراوان میتواند پرهزینه باشد و متن ماژول رمزگذاریشده قابل بازیابی نیست.
- جمعکردن میانگینها بدون توجه به وزن تعداد اجرا یا بازه زمانی.
- اجرای Query بدون فیلتر روی پایگاه داده پرترافیک و انتقال خروجی حجیم به ابزار گزارشگیری.
- نادیدهگرفتن تفاوت نسخهها و استفاده از ستون یا نمایی که در مقصد وجود ندارد.
ملاحظات کارایی و بهترین روشها
ابتدا با شناسه، بازه زمانی یا آمار اجرا دامنه را محدود کنید و سپس متن کامل را بخوانید.
- سؤال تحلیلی را قبل از نوشتن Query مشخص کنید؛ گزارش بدون سؤال فقط حجم داده تولید میکند.
- ابتدا شناسهها و بازههای لازم را محدود کنید و ستونهای سنگین را در مرحله آخر بخوانید.
- برای روندهای تاریخی، Snapshot کنترلشده با زمان نمونهبرداری بسازید و از کپی کامل داده خام بپرهیزید.
- Query تحلیلی را روی محیط مشابه تولید آزمایش کنید و هزینه IO، CPU و زمان را ثبت کنید.
- هر Hint، Plan Forcing یا تغییر تنظیمات را با خط مبنا، مسئول تغییر و برنامه بازگشت مستند کنید.
کاربرد در یک پروژه واقعی
فرض کنید سامانه فروش در ساعات اوج کند میشود. تیم پشتیبانی ابتدا query_id یا plan_idهای پرهزینه را پیدا میکند، سپس از sys.query_store_query_text برای ردیابی متن دقیق یک گزارش کند و یافتن عبارتهایی که الگوی خاصی از نام جدول یا پارامتر را دارند. استفاده میکند. خروجی با متن Query، Plan، آمار Runtime و Waitها تطبیق داده میشود تا مشخص شود مشکل از تغییر طرح، افزایش حجم، قفل، IO، حافظه یا تنظیم مدیریتی است.
در مرحله بعد یک گزارش دورهای ساخته میشود که فقط انحرافهای معنادار را نگهداری میکند. این رویکرد از انباشتهشدن داده بیمصرف جلوگیری میکند و زمان واکنش تیم را کاهش میدهد. معیار موفقیت نیز باید قابل اندازهگیری باشد؛ برای نمونه کاهش صدک ۹۵ مدت اجرا، افت CPU یا حذف بازگشت مکرر به طرح نامطلوب.
سؤالات متداول
sys.query_store_query_text دقیقاً چه مسئلهای را حل میکند؟
این نما متن T-SQL، شناسه متن، هندل عبارت و وضعیت متن محدود یا رمزگذاریشده را نگهداری میکند. و برای تبدیل دادههای داخلی Query Store به گزارش قابل تحلیل استفاده میشود.
برای شروع کار با sys.query_store_query_text کدام ستونها مهمترند؟
ستونهای query_text_id، query_sql_text، statement_sql_handle، is_part_of_encrypted_module نقطه شروع مناسبی هستند؛ سپس بر اساس سناریو ستونهای تکمیلی افزوده میشوند.
آیا استفاده از sys.query_store_query_text برای گزارش مدیریتی مناسب است؟
بله، به شرط آنکه داده فنی خام به شاخصهایی مانند روند، رتبه، تغییر نسبت به بازه قبل و اقدام پیشنهادی تبدیل شود.
چطور میتوان از داده sys.query_store_query_text در پروژه سازمانی استفاده کرد؟
میتوان یک Job جمعآوری، جدول Snapshot و داشبورد ساخت تا سناریوی «ردیابی متن دقیق یک گزارش کند و یافتن عبارتهایی که الگوی خاصی از نام جدول یا پارامتر را دارند.» بهصورت دورهای پایش شود.
sys.query_store_query_text با نماهای دیگر Query Store چه تفاوتی دارد؟
تمرکز این نما روی «متن پرسوجوهای ثبتشده در Query Store» است؛ در حالی که نماهای متن، query، plan، runtime و wait هر کدام لایه متفاوتی از زنجیره تحلیل را ارائه میکنند.
برای پیادهسازی گزارش حرفهای sys.query_store_query_text چه خدمتی لازم است؟
طراحی Query، مدل نگهداری Snapshot، کنترل دسترسی، ساخت داشبورد و تعریف آستانه هشدار معمولاً به تحلیل و پیادهسازی تخصصی SQL Server نیاز دارد.
رایجترین خطا در کار با sys.query_store_query_text چیست؟
جستوجوی LIKE با الگوی آغازشونده با درصد روی متنهای فراوان میتواند پرهزینه باشد و متن ماژول رمزگذاریشده قابل بازیابی نیست.
مهمترین نکته Performance برای sys.query_store_query_text چیست؟
ابتدا با شناسه، بازه زمانی یا آمار اجرا دامنه را محدود کنید و سپس متن کامل را بخوانید.
بهترین روش نگهداری گزارشهای مبتنی بر sys.query_store_query_text چیست؟
خروجی خام را بیهدف کپی نکنید؛ فقط شاخصهای موردنیاز را با زمان نمونهبرداری، شناسه پایگاه داده و نسخه موتور در جدول تاریخچه ذخیره کنید.
sys.query_store_query_text در چه نسخههایی در دسترس است؟
SQL Server 2016 و نسخههای بعدی. پیش از استقرار اسکریپت روی چند سرور، وجود نما و ستونهای مورد استفاده را کنترل کنید.
سؤالات مصاحبه SQL Server
- توضیح دهید sys.query_store_query_text چه دادهای میدهد و در چه مرحلهای از تحلیل Query Store استفاده میشود.
- کلید اصلی اتصال sys.query_store_query_text به نمای مکمل چیست و Join اشتباه چه اثری دارد؟
- چگونه یک Query پرهزینه روی sys.query_store_query_text را به نسخه سبکتر تبدیل میکنید؟
- برای کنترل سازگاری نسخه sys.query_store_query_text چه الگویی پیشنهاد میدهید؟
- چگونه نتیجه حاصل از sys.query_store_query_text را با آمار Runtime یا Waitها اعتبارسنجی میکنید؟
چکلیست نهایی
- فعال بودن Query Store و وجود داده کنترل شده است.
- وجود نمای sys.query_store_query_text و ستونهای مورد استفاده بررسی شده است.
- فیلتر شناسه و بازه زمانی قبل از Joinهای سنگین اعمال شده است.
- خروجی نمونه با متن Query، Plan یا شاخص مکمل تطبیق داده شده است.
- نتیجه، فرضیه و اقدام پیشنهادی بهصورت قابل ممیزی ثبت شده است.
جمعبندی
sys.query_store_query_text برای متن پرسوجوهای ثبتشده در Query Store یک ابزار تخصصی و ارزشمند است. استفاده درست از آن نیازمند شناخت ستونها، اتصال دقیق به سایر نماها، رعایت تفاوت نسخهها و تفسیر داده در بستر زمان و بار کاری است. ده مثال این مقاله مسیر را از خواندن پایه تا گزارش عملیاتی و کنترل Performance پوشش داد.
برای مشاهده جایگاه این نما در کل معماری، به مقاله مادر نماهای کاتالوگ Query Store بازگردید.
خدمات برنامهنویسی و پایگاه داده
برنامهنویسی در اصفهان؛ قبول سفارشهای برنامهنویسی و پایگاه داده با شماره 09131253620.
انجام پروژه و آموزش تخصصی
انجام پروژههای برنامهنویسی، آموزش برنامهنویسی و آموزش پایگاه داده SQL Server برای اشخاص، شرکتها و مجموعههای آموزشی انجام میشود.
مجموعهای معتبر با سابقه فعالیت حرفهای از سال ۱۳۷۵ شمسی
از سال ۱۳۷۵ شمسی تاکنون در زمینه طراحی و اجرای پروژههای برنامهنویسی، پایگاه داده، سیستمهای تحت وب، وبسایت و راهکارهای نرمافزاری فعالیت میکنیم.
برای سفارش پروژههای برنامهنویسی و پایگاه داده، سیستمهای تحت وب، وبسایت و راهکارهای نرمافزاری جدید، با شماره تلفن همراه 09131253620 تماس حاصل فرمایید.
ایتا، واتساپ و تماس مستقیم: +989131253620
تماس با ما