遊標真的有多慢，以及哪種更好的替代方案？

Question

我一直在閱讀遊標是漂亮的slow和一個應該除非選擇避開它們。我試圖優化我的存儲過程，其中一個使用遊標。它經常被我的應用程序和許多用戶（20000）和行更新所調用。我在想，也許我應該使用別的東西作爲替代。

我想要做的或想要的是獲取記錄列表，然後根據每個行值進行操作。因此，對於e.g我們不得不說 -

Employee - Id,Name,BenefitId,StartDate,EndDate 

因此，基於benefitId我需要做的起始日期使用日期和結束日期和更新員工的詳細信息之間的日期不同的計算。我只是用這個人爲的例子來說明我的情況。

你對此有何看法？使用臨時表或用戶定義函數的遊標是否有更好的選擇？你應該什麼時候選擇他們，或者我們應該永遠不使用遊標？謝謝大家的幫助。

Answer 1

我已經改變了遊標和移動距離超過24小時的處理時間不到一分鐘。

，以幫助您瞭解如何解決與基於集合的邏輯你的PROC，請閱讀本： http://wiki.lessthandot.com/index.php/Cursors_and_How_to_Avoid_Them

Answer 2

我曾經將存儲過程從遊標更改爲基於邏輯的設置。運行時間從8小時變爲22秒。這就是我們正在談論的那種差異。

而不是一次採取不同的行動記錄，使用數據的幾個通行證。更新並設置field1 = A，其中field2爲X，然後更新並設置field1 = B，其中field2爲Y等。

Answer 3

遊標會逐行處理，或者如果您的名字是「Row By Agonizing Row」 Jeff Moden。

這只是one example如何做基於集合的SQL編程，而不是RBAR，但它最終取決於您的光標在做什麼。

而且，看看這個StackOverflow上：

RBAR vs. Set based programming for SQL

Answer 4

首先，這聽起來像你想在你的存儲特效把一些業務邏輯。這通常是你想避免的事情。更好的解決方案是有一個封裝了業務邏輯的中間層。這樣你的數據層就保持純粹的數據。

要回答你原來的問題，這真的取決於你使用的遊標。在某些情況下，您可以使用表變量或臨時表。你必須記住釋放臨時表，所以我建議儘可能使用表變量。但有時候，使用遊標是沒有辦法的。也許原來的DBA沒有足夠標準化（或標準化太多），並且你不得不使用遊標遍歷多個表，而沒有任何外鍵關係。