Cursor در SQL Server

مقدمه

در دنیای پیچیده و پرسرعت توسعه پایگاه‌داده با SQL Server، مدیریت داده‌ها اغلب فراتر از اجرای ساده کوئری‌ها است.

یکی از ابزارهایی که همیشه مورد بحث بوده و جایگاه خاصی در ذهن توسعه‌دهندگان دارد، Cursor است.

این ابزار امکان پردازش ردیف‌به‌ردیف داده‌ها را فراهم می‌کند، اما هم‌زمان به‌عنوان یک عامل بالقوه کاهش عملکرد نیز شناخته می‌شود.

Cursor در SQL Server چیست؟

Cursor در SQL Server ابزاری برای پردازش رکوردها به‌صورت ردیف‌به‌ردیف (Row by Row) است.

به‌صورت پیش‌فرض، SQL Server عملیات را به شکل مجموعه‌ای (Set-Based) انجام می‌دهد.

اما زمانی که نیاز داشته باشیم هر ردیف را جداگانه بررسی یا تغییر دهیم، از Cursor استفاده می‌کنیم.
تعریف ساده Cursor
Cursor یک ساختار کنترلی است که:
1.    روی نتیجه یک Query باز می‌شود.
2.    هر بار یک رکورد را واکشی (Fetch) می‌کند.
3.    روی آن پردازش انجام می‌دهد.
4.    به رکورد بعدی می‌رود

چرا از Cursor در SQL Server استفاده می‌کنیم؟

قبل از استفاده از Cursor باید بدانیم چه زمانی واقعاً به آن نیاز داریم.

Cursor ابزار قدرتمندی است، اما استفاده نادرست از آن باعث کاهش شدید Performance می‌شود.
مهم‌ترین دلایل استفاده از Cursor

•     زمانی که پردازش به ترتیب رکوردها وابسته باشد.

•     زمانی که نتیجه هر ردیف به نتیجه ردیف قبلی وابسته باشد.

•     اجرای عملیات پیچیده روی هر رکورد

•     ارسال اطلاعات هر رکورد به سرویس خارجی

•     اجرای Dynamic SQL برای هر سطر

مثال کاربردی: ارسال ایمیل برای هر کاربر

فرض کنید لیستی از کاربران داریم و باید برای هر کاربر ایمیل شخصی‌سازی شده ارسال کنیم.

اگر منطق ارسال برای هر رکورد متفاوت باشد، Cursor می‌تواند انتخاب مناسبی باشد.

 ساختار و اجرای Cursor در SQL Server

Cursor در SQL Server ابزار قدرتمندی برای پردازش ردیف‌به‌ردیف داده‌هاست.

در این بخش، یک مثال عملی و مراحل اجرای Cursor را با زبانی ساده توضیح می‌دهیم:

DECLARE @UserId INT
DECLARE @Email NVARCHAR(100)

DECLARE UserCursor CURSOR FOR
SELECT Id, Email FROM Users

OPEN UserCursor

FETCH NEXT FROM UserCursor INTO @UserId, @Email

WHILE @@FETCH_STATUS = 0
BEGIN
    PRINT 'Sending email to: ' + @Email
    FETCH NEXT FROM UserCursor INTO @UserId, @Email
END

CLOSE UserCursor
DEALLOCATE UserCursor

 مراحل اجرای Cursor

قبل از پیاده‌سازی Cursor، لازم است با مراحل آن آشنا باشید:

1. Declare Cursor – تعریف Cursor و انتخاب داده‌ها
2. Open Cursor – باز کردن Cursor برای دسترسی به داده‌ها
3. Fetch – خواندن اولین ردیف از Cursor
4. Loop – اجرای حلقه برای پردازش تمام ردیف‌ها
5. Close – بستن Cursor پس از پایان کار
6. Deallocate – آزادسازی منابع سیستم

 اگر مرحله Deallocate اجرا نشود، منابع سیستم آزاد نشده و ممکن است باعث کاهش کارایی سرور شود.

 انواع Cursor در SQL Server و تاثیر آن‌ها بر عملکرد

انتخاب نوع Cursor در SQL Server نقش مهمی در کارایی و سرعت اجرای کوئری‌ها دارد.

هر نوع Cursor رفتار و کاربرد متفاوتی دارد و شناخت درست آن‌ها برای توسعه‌دهندگان و مدیران پایگاه داده ضروری است.

 1. STATIC Cursor

•  یک Snapshot از داده‌ها ایجاد می‌کند و وضعیت آن لحظه را ذخیره می‌کند.

•  تغییرات بعدی در داده‌ها را نمایش نمی‌دهد.

•  مصرف بالایی از TempDB دارد، بنابراین برای داده‌های بزرگ مناسب نیست.

 2. DYNAMIC Cursor

•  تمام تغییرات داده‌ها را در زمان واقعی (Real-Time) نشان می‌دهد.

•  نسبت به سایر Cursorها کندتر است و روی داده‌های بزرگ ممکن است عملکرد پایین‌تری داشته باشد.

 3. KEYSET Cursor

•  کلیدهای ردیف‌ها ثابت هستند، اما مقادیر ستون‌ها می‌توانند تغییر کنند.

•  ترکیبی از ویژگی‌های STATIC و DYNAMIC است و برای برخی سناریوهای متوسط مناسب است.

 4. FAST_FORWARD Cursor

•  تنها قادر به حرکت Forward است و فقط Read-Only عمل می‌کند.

•  به دلیل سادگی و محدودیت‌ها، سریع‌ترین نوع Cursor محسوب می‌شود.

 در اکثر پروژه‌های واقعی، وقتی مجبور به استفاده از Cursor هستید، FAST_FORWARD بهترین انتخاب برای حفظ کارایی است.

  نکته : استفاده از Cursor معمولاً در پروژه‌های خاص و کوچک توصیه می‌شود؛ برای پردازش حجم بالای داده‌ها، روش‌های Set-Based SQL همیشه کاراتر هستند.

 محدودیت‌های استفاده از Cursor در SQL Server

قبل از پیاده‌سازی Cursor در SQL Server، باید با محدودیت‌ها و ریسک‌های آن آشنا باشید.

استفاده نادرست یا بی‌رویه از Cursor یکی از دلایل اصلی کاهش کارایی و مشکلات عملکردی در پروژه‌های بزرگ Enterprise است.

 مهم‌ترین محدودیت‌ها و ریسک‌های Cursor:

  کاهش شدید عملکرد (Performance)

پردازش ردیف به ردیف باعث کندی اجرای کوئری‌ها می‌شود.

  مصرف بالای CPU

 Cursorها منابع پردازشی زیادی می‌گیرند، به‌ویژه روی داده‌های حجیم.

  افزایش عملیات IO

خواندن و نوشتن مکرر باعث فشار روی دیسک می‌شود.

  قفل شدن جداول (Locking)

اجرای طولانی Cursor می‌تواند باعث Deadlock و بلاک شدن سایر عملیات شود.

  مصرف TempDB بالا

برخی Cursorها داده‌ها را در TempDB ذخیره می‌کنند و فشار زیادی روی سرور ایجاد می‌کنند.

  مقیاس‌پذیری پایین

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

 نکته : استفاده از روش‌های Set-Based SQL همیشه ارجح است و در اکثر پروژه‌های واقعی، جایگزین بهینه‌تری نسبت به Cursor محسوب می‌شود.

 چگونه می‌توان Cursorها را در SQL Server جایگزین کرد؟

استفاده از Cursor در SQL Server می‌تواند چندین برابر کندتر از پردازش‌های مجموعه‌ای (Set-Based) باشد و عملکرد پایگاه داده را به شدت کاهش دهد.

در معماری مدرن پایگاه داده، یک اصل مهم وجود دارد:

 اگر می‌توان یک مسئله را با یک Query مجموعه‌ای حل کرد، هرگز از Cursor استفاده نکنید.

در ادامه روش‌های مؤثر برای جایگزینی Cursor را بررسی می‌کنیم:

 1. استفاده از عملیات Set-Based

بهترین و سریع‌ترین جایگزین Cursor، استفاده از عملیات مجموعه‌ای است:

•  UPDATE با JOIN برای بروزرسانی چندین ردیف به صورت همزمان

•  DELETE با Subquery برای حذف ردیف‌ها بر اساس شرط

•  MERGE برای ادغام داده‌ها در یک عملیات واحد

•  INSERT INTO SELECT برای درج داده‌ها از یک جدول به جدول دیگر

 2. استفاده از CTE (Common Table Expression)

CTE امکان ایجاد یک جدول موقت مجازی را می‌دهد که می‌توان روی آن عملیات مجموعه‌ای انجام داد:

WITH CTE AS (
    SELECT Id, ROW_NUMBER() OVER (ORDER BY Id) AS RowNum
    FROM Users
)
SELECT * FROM CTE;

 3. استفاده از توابع Window

توابع Window قابلیت پردازش ردیف‌ها در یک مجموعه داده را بدون Cursor فراهم می‌کنند، از جمله:

•  `()ROW_NUMBER`

•  `()RANK`

•  `() OVER()SUM`

•  `()LAG` و `()LEAD`

 4. استفاده از Table Variable یا Temp Table

گاهی می‌توان داده‌ها را در یک جدول موقت یا Table Variable ذخیره کرد و سپس عملیات مجموعه‌ای روی آن انجام داد تا نیاز به Cursor حذف شود.

مثال واقعی: جایگزینی Cursor با Query بهینه
پروژه
می‌خواهیم مجموع فروش هر مشتری را محاسبه کنیم.
❌ روش اشتباه با Cursor
✔ روش صحیح با GROUP BY:

SELECT CustomerId, SUM(Amount) AS TotalAmount
FROM Orders
GROUP BY CustomerId

نتیجه:

•     سرعت بالاتر
•     مصرف منابع کمتر
•     مقیاس‌پذیری بهتر

🌟 آیا می‌خواهید به یک متخصص پایگاه داده تبدیل شوید و در دنیای فناوری اطلاعات بدرخشید؟

با دوره آموزشی SQL Server ما، شما می‌توانید به راحتی و با روشی عملی، تمام مهارت‌های لازم را یاد بگیرید!

این دوره به شما آموزش می‌دهد که چگونه داده‌ها را به بهترین شکل مدیریت کنید، گزارش‌های قدرتمند بسازید و به تحلیل‌های عمیق دست یابید.

با محتوای جذاب و پروژه‌های واقعی، شما نه تنها تئوری را یاد می‌گیرید، بلکه توانایی‌های عملی خود را نیز تقویت می‌کنید.

پس فرصت را از دست ندهید! همین امروز به جمع یادگیرندگان ما بپیوندید و اولین قدم را به سوی آینده شغلی روشن‌تر بردارید!

 ⇐همین حالا شروع کنید و به دنیای داده‌ها بپیوندید!

ارتباط Cursor در SQL Server با ساختار Queue در #C

در برنامه‌نویسی مدرن، استفاده از Queue در #C برای پردازش ترتیبی داده‌ها کارایی بالاتری نسبت به اجرای ردیف‌به‌ردیف با Cursor دارد.

فهم تفاوت این دو روش به بهینه‌سازی عملکرد و مقیاس‌پذیری سیستم کمک می‌کند.

تفاوت‌های اصلی Cursor و Queue

چه زمانی Queue بهتر است؟

منطق پردازش پیچیده است و باید در سطح اپلیکیشن انجام شود.

داده‌ها ابتدا با Query بهینه از پایگاه داده خوانده می‌شوند.

پردازش اصلی با Queue در #C انجام می‌شود تا مقیاس‌پذیری و سرعت افزایش یابد.

 نکته : این معماری ترکیبی، مزایای پردازش مجموعه‌ای در SQL Server و انعطاف‌پذیری صف در #C را بهینه می‌کند و استفاده از Cursor را کاهش می‌دهد.

پرسش‌های Cursor در SQL Server

1. آیا Cursor باعث Lock شدن جدول می‌شود؟

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

2. آیا می‌توان Cursor را کاملاً حذف کرد

در بسیاری از پروژه‌های حرفه‌ای، بله. با استفاده از:

• JOIN
• CTE
• Window Functions
• MERGE

پردازش در لایه اپلیکیشن

نتیجه‌گیری

Cursor در SQL Server ابزار مفیدی برای پردازش ردیف‌به‌ردیف داده‌هاست، اما استفاده نابه‌جا از آن باعث کاهش عملکرد و فشار روی منابع می‌شود.

در اغلب موارد، روش‌های مجموعه‌ای مانند JOIN، CTE و توابع Window سریع‌تر، بهینه‌تر و مقیاس‌پذیرتر هستند.

تنها در سناریوهای خاص که پردازش ترتیبی ضروری است، Cursor یا ترکیب پایگاه داده با Queue در لایه اپلیکیشن پیشنهاد می‌شود.

در نهایت، انتخاب هوشمندانه روش پردازش، کلید حفظ سرعت و پایداری سیستم است.