關於「模糊」遊標事實的問題

我知道基於集合的解決方案是理想的，並且通常優於遊標。所以，請。通過放棄答案保存你的和我的時間「不要使用遊標，使用基於集合的操作」。我問這個，因爲我的谷歌搜索沒有給出任何答案和知識可能來自經驗：關於「模糊」遊標事實的問題

1）下次提取到V來去當我打開光標（FAST_FORWARD /靜態），是有區別在while循環內使用'取下一個'和'取下一個'之間？在性能上，記錄順序訪問等

2）ROW_NUMBER + SELECT/WHILE VS靜態遊標據我所知，靜態遊標創建具有選擇的數據臨時表和越過該臨時表。那麼，是否有理由使用select row_number() ..., ... from ... into ...並用索引變量和select * from #tmp table where RowNumber = @IndexVar迭代它？

3）FAST_FORWARD - 它可以分解嗎？如果我有一個fast_forward本地遊標，並且在這個遊標內插入/更新操作在遊標選擇的表上執行，是否有任何問題？（可能的週期等？）

4）計劃強迫有沒有辦法強制fast_forward光標使用靜態/動態計劃？

非常感謝你對你的答案

PS：對於那些你真的很好奇，是的，這個問題可以改寫成一個基於集合的方法，但由於從更高了，新行一些決定在主表中創建必須使用存儲過程創建/插入。

來源

2013-07-09 Vladislav Zalesak

如何讓存儲過程阻止您使用基於集合的方法？存儲過程可以寫成使用基於集合的代碼。 – HLGEM

這看起來像一個多個問題。也許考慮把你的每一個數字分解成一個單獨的問題？ –

@HLGEM：如果您的意思是執行一個存儲過程，其中存儲過程執行基於集合的插入/更新...否。爲什麼？ 1st）現在它是一個存儲過程，它通過一個遊標並創建一個存儲過程。讓我們稱之爲CreateUpdateRecord。這個過程只創建/更新一個和一個記錄，你可以把它看作是一個像C＃這樣的標準語言的構造器/設置器。這是在我加入該項目之前完成的，現在我無法做任何事情。在被問及時，這是一個很難改變的難題。我唯一的選擇是儘可能快地執行它450 000。 –

是有使用之間的差異「獲取下一個從」和「獲取下一個」 while循環

裏面沒有 - NEXT是，如果沒有指定選項的默認

那麼，是否有任何理由使用select row_number() ..., ... from ... into ...並用索引變量和select * from #tmp table where RowNumber = @IndexVar迭代它？

我會假定靜態遊標具有優化功能，可以更快地創建臨時表並在每次迭代中搜索特定行，但是我必須嘗試一下。

如果我有一個fast_forward局部遊標，並且在這個遊標內插入/更新操作是在遊標選擇的表上執行的，有什麼問題嗎？（可能的週期等？）

我不知道你所說的「循環」的意思 - 如果基礎數據更改光標也會改變（除非你宣佈它作爲STATIC）

有沒有辦法強制fast_forward光標使用靜態/動態計劃？

我從來沒有嘗試過，但你可以嘗試在你的SELECT使用OPTION(USE PLAN ...)當你定義光標。我想不出爲什麼它不起作用的原因。

我得到瘋狂這和谷歌是無能

谷歌剛剛報告把什麼人在互聯網上...爲什麼你瘋了嗎？你想解決什麼問題？

來源

2013-07-09 21:46:53

我正在爲一個400k的記錄插入生氣，這個插入需要40分鐘以上（當我離開時仍在運行），而100k需要大約4分鐘。至於 - 「如果底層數據發生變化，遊標也會改變」 - 就在我正確理解這一點的時候：在大約40萬條記錄的表上做一個fast_forward光標，在這個過程中插入大約1500條並更新其他385條記錄導致遊標一遍又一遍的重建？ –

好吧，400k記錄的光標插入/更新週期在6小時後崩潰（讓它在夜間運行，事務日誌達到約29gb），硬盤壞了。在一個遊標週期中，大約30次插入/更新（每行一個）完成 –

NEXT是默認提取選項，所以FETCH = FETCH NEXT
靜態/動態指的是與否，如果你插入新的值到靜態遊標結果集通過遊標結果集進行的更改都反映，即它不會循環這些，它是當光標被聲明/打開時的結果，就是這樣，我相信你的理解是正確的。
我不確定。
我不確定你的意思，你可以在聲明遊標時指明動態或靜態。

來源

2013-07-09 21:43:22

關於「模糊」遊標事實的問題

回答

相關問題