什么時候更喜歡悲觀的事務隔離模型而不是樂觀的模型？

Question

難道我理解正確的是被用於並發性的悲觀事務（TX）隔離模式只表/行鎖提示？
換句話說，在使用SQL Server提供的樂觀TX隔離（2005年及更高版本）期間，何時可以使用表/行鎖定提示？

如果稍后在SQL Server2005 +中提供悲觀的TX隔離級別/提示，則后者是否提供內置的樂觀（又名快照或版本控制）並發隔離？
我確實讀過，悲觀的選擇是遺留的，不再需要，盡管我對此表示懷疑。

此外，如果SQL Server2005 +內置了樂觀（又名快照，又稱為快照版本控制）TX隔離級別，那么何時需要手動編寫樂觀並發功能代碼？

最后一個問題的靈感來自閱讀：

• “ SQL Server中的樂觀並發”（2007年9月28日）

描述自定義編碼以在SQL Server中提供版本控制。

Answer 1

樂觀並發需要更多資源，發生沖突時會花費更多。

兩個會話可以讀取和修改值，並且僅當它們嘗試同時應用更改時才會發生沖突。 這意味着在並發更新的情況下，兩個值都應存儲在某個位置（當然這需要資源）。

同樣，當發生沖突時，通常應回滾整個事務或重新獲取游標，這也很昂貴。

悲觀並發模型使用鎖定，因此降低了並發級別，但提高了性能。

在有兩個並發任務的情況下，等待第二個任務等待釋放鎖要比在兩個同時工作上花費CPU時間和磁盤I/O ，然后回滾不幸的工作並重做要便宜得多。

假設您有這樣的查詢：

UPDATE  mytable
SET     myvalue = very_complex_function(@range)
WHERE   rangeid = @range

，其中very_complex_function從mytable本身讀取一些數據。 換句話說，此查詢將轉換mytable的子集，該子集共享range的值。

現在，當兩個函數在同一范圍內工作時，可能會出現兩種情況：

1. 悲觀的：第一個查詢鎖定，第二個查詢等待。 第一個查詢在10秒內完成，第二個查詢也完成。 總計： 20秒。

2. 樂觀：兩個查詢都獨立工作（在同一輸入上）。 這將在它們之間共享CPU時間以及切換時的一些開銷。 他們應該將中間數據保留在某個地方，因此數據將存儲兩次（這意味着兩次I/O或內存）。 假設兩者在15秒內幾乎同時完成。

   但是，當需要提交工作時，第二個查詢將發生沖突，並且必須回滾其更改（例如，花費相同的15秒）。 然后，它需要重新讀取數據並使用新數據集（ 10秒）再次進行工作。

   結果， 兩個查詢的完成時間都比悲觀的鎖定要晚： 15和40秒vs. 10和20 。

如果稍后在SQL Server2005 +中提供悲觀的TX隔離級別/提示，則后者是否提供內置的樂觀（又名快照或版本控制）並發隔離？

樂觀的隔離級別是樂觀的。 當您期望對數據進行高爭用時，不應使用它們。

順便說一句， SQL Server 2000也提供了樂觀隔離（用於讀取查詢）。

Answer 2

我在這里有一個詳細的答案： 開發可以生存並發的修改

Answer 3

我認為這里的術語有些混亂。

樂觀鎖定/樂觀並發/ ...技術是一種用於避免以下情況的編程技術：

• 開始交易
• 讀取數據，對其設置“讀取”鎖，以防止對我們的數據進行任何刪除/修改
• 在用戶屏幕上顯示數據
• 等待用戶輸入，鎖保持激活狀態
• 繼續等待用戶輸入，鎖定仍然阻止任何寫入/修改
• 用戶輸入永遠不會（出於任何原因）
• 交易超時（通常不會很快，因為必須給用戶合理的時間輸入其輸入）。

樂觀鎖定將其替換為以下內容：

• 開始交易讀取
• 讀取數據，對其設置“讀取”鎖，以防止對我們的數據進行任何刪除/修改
• 結束事務READ，釋放剛剛設置的讀取鎖
• 在用戶屏幕上顯示數據
• 等待用戶輸入，但同時其他事務可以修改/刪除數據
• 用戶輸入到達
• 開始交易WRITE
• 驗證數據是否保持不變，如果有則引發異常
• 應用用戶更新
• 結束交易WRITE

因此，要進行一些數據獲取，更改和更新的單個“用戶事務”由兩個不同的“數據庫事務”組成。 通常所謂的“隔離級別”適用於那些數據庫事務。 您引用的“樂觀鎖定”適用於“用戶事務”。

事情變得更加復雜，因為從廣義上講，“隔離數據庫事務部分”可能有兩種完全不同的策略：

• MVCC
• 2相鎖定

我認為“快照版本隔離級別”意味着MVCC技術（它的各種可能的變體之一）正在用於數據庫事務。 其他眾所周知的隔離級別更多地應用於使用2PL作為序列化（/ isolation）技術的事務隔離。 （將它們混在一起可能會變得混亂...）