SQL Server 2005 Beta 2 快照隔離

理解併發控制

就像在使用情境中看到的，在控制併發時主要使用兩種模型：悲觀併發和樂觀併發。在基於悲觀併發控制的系統下，鎖定被用於阻止使用者以影響其他使用者的方式修改資料。一旦應用了鎖定，其他使用者就不能執行可能與鎖定衝突的操作，直到所有者釋放鎖定。這種級別的控制通常用於存在較多資料爭用的環境，以及如果/當併發突出產生時使用鎖定來保護資料的成本小於回滾事務的成本的環境中。相反，在基於樂觀併發控制的系統中，使用者在讀取資料時並不鎖定資料。在執行更新時，系統會檢查是否有另一個使用者在資料被讀取後更改了資料。如果另一個使用者更改了資料，就會產生一個錯誤。通常，使用者收到錯誤後會回滾事務，重新提交（應用程式/環境相關）和/或啟動。這被稱為樂觀併發，因為它主要用於低資料爭用的環境中，以及讀取時偶然回滾事務的成本超過鎖定資料的成本的環境中（請注意，在 Read Committed 下執行的更新和 Snapshot Isolation 下執行的更新不會衝突，因此不會導致回滾成本）。

在 SQL Server 2005 之前，事務是以悲觀方式控制的，這意味著所有事務都獲得鎖定。儘管鎖定是多數應用程式的最佳併發控制選擇，但是它也會導致編寫器阻止讀取器。如果某個事務更改了某一行，那麼在編寫器提交之前另一個事務就不能讀取該行。在一些情況下，等待更改完成是正確的響應；但在另一些情況下，以前的行事務一致性狀態就足夠了。

基於快照的隔離級別使得讀取器能夠取得先前提交的行值，代價是在修改行時必須保留此版本——即使“當前”沒有人正在訪問資料也是一樣。這意味著所有選擇、更新和刪除（但不插入）語句可能都要付出版本控制的代價（進出版本儲存的額外的 I/O）。您必須作出決定，使得這一交換可以在開銷和效能的代價下獲得更好的併發。要說明的很重要的一點是，儘管可能需要花費更多代價來執行每次查詢（因為版本控制），但是最終的結果可能是您可以支援更多的吞吐量（因為爭用降低了）。它可以應用在爭用消耗吞吐量的環境中，這很重要；如果您使用這種技術作為不是由爭用引起的效能問題的解決方案，那麼您可能就是在解決錯誤的問題，並且實際上，會降低您的系統吞吐量。

一般說來，當資料庫透過基於版本控制的隔離自動控制您的資料檢視時，應用程式程式設計會比價容易。在這種環境中，您較少擔心死鎖和阻止，而是在管理性管理開銷和效能上額外付出了一點代價。在很多情況下，對於 TempDB 來說可能更容易選擇在管理性開銷和提供更多磁碟吞吐量上付出代價。如果所有基於查詢的快照都只能提供讀取一致性，而不能提供後續修改的基礎；那麼就不需要任何應用程式重試邏輯。但是，您最終可能會在使用快照隔離級別並且後來執行了更新的事務中遇到衝突；如果版本是“陳舊的”，那麼您可能需要使用重試邏輯進行更新。