ORDER BY應該對遊標性能產生積極影響，爲什麼？

我有一個腳本，看起來像這樣（Id1和Id2構成表primiary鍵）ORDER BY應該對遊標性能產生積極影響，爲什麼？

DECLARE @Id1 AS int, 
     @Id2 AS smallint; 

DECLARE c CURSOR FAST_FORWARD FOR SELECT Id1, Id2 FROM dbo.someTable ORDER BY Id1, Id2 
OPEN c 
    FETCH NEXT FROM c INTO @Id1, @Id2 
    WHILE @@FETCH_STATUS = 0 
     BEGIN 
      --Do stuff that do not depend on row order (getting random values and updating some of the fields) 
      FETCH NEXT FROM c INTO @Id1, @Id2 
     END 
CLOSE c 
DEALLOCATE c

隨着ORDER BY Id1, Id2條款起來比沒有它要快得多。

我預計訂購記錄會浪費一些時間，而不是時間增益。

我有其他類似的腳本在其他表類似的ORDER BY條款獲得較低的速度。

所以我想知道爲什麼我這ORDER BY子句可以加快遊標，但不是所有的遊標。

來源

2017-10-16 TTT

你有看過執行計劃嗎？你可以發佈他們嗎？ – Leonidas199x

如果你關心性能，最好的辦法就是擺脫遊標。從發佈的代碼片段和更新每行的描述中，不需要光標。它所做的只是減緩這一點，所以你可以更新RBAR（通過摺疊行來更新）。告訴我們邏輯，我們可以展示如何做到基於集。 –

我知道光標的聲譽很差，但我需要在每個字段上做各種事情......有些需要randoms值，有些需要類似於其他字段的隨機值，需要計算一些隨機值，還有一些需要提取從一個臨時表......我在StackOverflow上發佈了一個關於這個問題的最佳方式的問題，我在「WITH」語句中獲得了嘗試使用昂貴JOIN的建議，結果都不準確或不完整，但我比較了性能和光標比那種情況更快。 – TTT

這取決於你在處理數據。如果您要插入表中，您希望按特定順序進行操作，以免碎片化索引。

來源

2017-10-16 13:43:20 cloudsafe

我實際上正在更新。 – TTT

ORDER BY應該對遊標性能產生積極影響，爲什麼？

回答

相關問題