موضوعی نهفته در Sort Operator

SQL Server بر اساس تعداد رکوردهای درخواستی از دو الگوریتم متفاوت جهت مرتب سازی داده‌ها استفاده می‌نماید. در این مقاله ما قصد داریم نشان دهیم که چگونه تعداد رکوردهای بازگشتی در یک Query عملکرد SQL Server را در مرتب سازی داده‌ها تغییر می‌دهد. جهت نمایش داده‌ها به صورت مرتب شده بر اساس یک یا چند ستون خاص از عبارت Order By استفاده می‌گردد. استفاده از این عبارت ممکن است اجتناب ناپذیر باشد مانند هنگامی که از Paging استفاده می‌نمائیم.

در این Demo ما از دیتابیس Stack Overflow و جدول Users این دیتابیس استفاده می‌نمائیم. جدول Users دارای یک Clustered Index است که بر روی ستون Id می‌باشد. می‌خواهیم اطلاعات ۱۰۰ کاربری را به دست بیاوریم که اخیرا در سایت ثبت نام نموده‌اند. کوئری زیر این کار را انجام می‌دهد:

Select Top 100 * From dbo.Users
Order By CreationDate Desc

تصویر زیر Plan اجرائی کوئری را نشان می‌دهد:

تصویر نشان می دهد که SQL Server از اپراتور Sort استفاده نموده و علامت Warning بر روی این اپراتور وجو ندارد.

حالا می‌خواهیم اطلاعات ۱۰۱ کاربر را به دست بیاوریم که اخیرا در سایت ثبت نام نموده‌اند. در واقع نسبت به کوئری قبلی یک ردیف بیشتر را واکشی می‌نمائیم. کوئری زیر این کار را انجام می‌دهد:

Select Top 101 * From dbo.Users
Order By CreationDate Desc

تصویر زیر Plan اجرائی کوئری جدید را نشان می دهد با وجود اینکه فقط یک ردیف بیشتر واکشی شده است اما علامت Warning بر روی اپراتور Sort وجود دارد:

تصویر بعدی متن علامت Warning را نمایش می‌دهد:

SQL Server مجبور شده است تقریبا ۱۴۵ هزار Page هشت کیلوبایتی داده را در دیتابیس سیستمی TempDB بنویسد و این کار سرعت اجرای کوئری را بسیار کاهش می‌دهد. مدت زمان اجرای کوئری دوم از مدت زمان اجرای کوئری اول بسیار بیشتر است، به عبارت دیگر کوئری اول خیلی سریع تر از کوئری دوم اجرا می‌شود.

چرا این اتفاق افتاد؟ آیا واکشی یک رکورد بیشتر می‌تواند سرعت اجرای کوئری را بسیار کاهش دهد؟

هنگامی که ۱۰۰ رکورد و کمتر به صورت مرتب شده واکشی می‌شوند SQL Server جهت مرتب سازی از یک الگوریتم خاص استفاده می‌نماید و هنگامی که ۱۰۱ رکورد و بیشتر به شکل مرتب شده واکشی می‌شوند، SQL Server الگوریتم دیگری را مورد استفاده قرار می‌دهد. در ادامه به بررسی بیشتر این موضوع می‌پردازیم. تصویر زیر نشان می‌دهد که در حالت واکشی ۱۰۰ رکورد به شکل مرتب شده میزان Memory ایده آل SQL Server جهت اجرای کوئری برابر با ۴ مگابایت است:

اما هنگامی که ۱۰۱ رکورد به شکل مرتب شده واکشی شده است میزان حافظه ایده آل SQL Server جهت اجرای کوئری تقریبا به چهار گیگابایت افزایش یافته است! تصویر زیر این مسئله را نشان می‌دهد:

تخمین میزان حافظه مورد نیاز جهت اجرای کوئری در حالت دوم که ۱۰۱ رکورد واکشی شده کلا بهم ریخته زیرا که الگوریتم مرتب سازی داده تغییر یافته است.

جهت برطرف نمودن مشکل فوق می توان از ایندکس گذاری مناسب استفاده نمود و اینکه فقط ستون‌های مورد نیاز باید واکشی شوند. اما باید به این نکته توجه داشت که در محیط عملیاتی کوئری‌ها به این سادگی نیستند و بخصوص در کوئری‌هایی که Join وجود دارد ممکن است ایندکس گذاری موجب حذف اپراتور Sort نشود. همواره تاکید بر این است که فقط ستون های مورد نیاز در کوئری در Select List قرار گیرند و از واکشی ستون‌های اضافی خودداری شود اما باید به این نکته توجه ویژه داشت که تاثیر تعداد رکوردهای بازگشتی در سرعت اجرای کوئری ها بسیار حائز اهمیت است.

در ادامه سوالاتی مرتبط با مرتب سازی داده ها مطرح می‌گردد:

بسیاری از Application ها از تکنیک صفحه بندی یا Paging جهت نمایش داده استفاده می‌نمایند. سوال مهم این است که آیا نیاز هست بیشتر از صد رکورد در هر صفحه به کاربر نمایش داده شود؟

سوال دیگر این است که آیا وب سرویس‌هایی که ریز رکوردها را واکشی می نمایند نیاز دارند داده‌ها را به صورت مرتب شده دریافت کنند؟

آیا این امکان وجود دارد که مرتب سازی داده در سمت گرید انجام شود و عبارت Order By از کوئری حذف گردد؟

آیا داده‌هایی که به یک جدول موقت جهت نگه داشتن نتایج میانی درج می‌شوند باید مرتب شده باشند؟ به صورت کلی در عبارت Insert Into …. Select … آیا به عبارت Order By نیاز است؟

نوشتن عبارت Order By در کوئری هزینه دارد. همچنین ایندکس گذاری Free نیست. ایندکس سبب افزایش حجم دیتا می‌شود، حجم و مدت زمان عملیات پشتیبان گیری را افزایش می‌دهد، عملیات DML را کند می‌کند، در مدت زمان اجرای دستور CheckDB DBCC تاثیر می‌گذارد و در آخر ایندکس‌ها نیاز به نگهداری دارند.