SQL快照隔離限制

Question

對於我的數據庫應用程序，對其某些查詢的事務使用快照隔離似乎是解決關鍵需求之一的完美選擇。

我很擔心，但是，如何選擇快照隔離（我認爲必須啓用數據庫範圍）現在咬我們，一旦我們開始得到非常高的音量。快照隔離的成本是多少？它是固定成本，線性還是幾何？

如果我是正確的被關注高容量，是否有類似快照可能有更好的整體性能，但需要更多的時間/專長來實現隔離應用程序級功能的戰略/模式？

感謝，

傑森

Answer 1

任何人誰是不是已經在鎖定和數據庫實現的專家，這可能是一個令人驚訝的難以受到周圍包裹你的頭腦。

我強烈建議由雨果Kornelis（SQL服務器MVP）閱讀本series of posts on snapshot isolation。到目前爲止，這是我在使用快照時對實用注意事項的最全面分析。

總結的主要問題：

• 當併發事務的特定組合將有可能違反約束（UNIQUE，外鍵等），SQL Server將回落到舊的方式做事。顯然，這對於可靠性很好，但對性能不利。快照並不是萬能的，它們不能取代良好的數據庫/查詢設計和智能鎖管理。
• 快照和觸發器可能無法在一起玩。如果您使用觸發器來保護數據完整性，這是特別危險的，但即使您不這樣做，幾乎所有的觸發器都必須能夠識別快照。

根據您編寫查詢的方式，您甚至可能甚至不需要使用觸發器以便以unexpected or inconsistent results結尾。

我不知道成本是固定的還是線性的，儘管它們絕對不是幾何的;無論如何，我都知道這有點讓人頭疼。人們經常談到它是一種即忘即忘的選擇，但事實是，事實並非如此，如果你不知道自己在做什麼，最終可能會發生突變（可能不會發現的變化）直到爲時已晚！）。

通過各種手段做，如果你確定它不會導致任何其他問題使用它。但是，如果您的任何邏輯不關心臟讀（這適用於多數系統中SELECT查詢的一半以上），那麼使用READ UNCOMMITTED（其確實涉及更多的「專業知識」）會得到更好的結果 - 您必須仔細考慮可能發生什麼以及何時發生）。

更新：在應用程序級別的替代

是彈簧想到的只有一個是緩存。有些數據框架可以爲你做（NHibernate，EF），在某些情況下，你甚至可能有第三層緩存，比如基於消息輸入緩存結果的Web服務，可能基於多個查詢的結果。我不會真的稱這爲「替代」，但我想如果這些是隻讀查詢並且底層數據不會頻繁更改，某種形式的緩存將對您的情況有效。當然，設計的考慮因素是，相對於您需要提供服務的數量，您可以承受的緩存數據量有多少;如果系統是大規模併發的，那麼這可能不會擴展。

除此之外，我個人不會選擇嘗試實現我自己的應用程序級事務「層」。也許有些人已經這樣做了，但我認爲有限的經驗可以與數百或數千名在DBMS上工作20年的最聰明的設計師競爭。

Answer 2

快照隔離，就是要更加閱讀比其他隔離級別高性能。通過將數據分隔成快照，事務不需要獲取行上的鎖，這可以防止阻塞和死鎖。

但是，它必須將行版本信息寫入tempdb數據庫。因此，對於每筆交易，都應該預計一些寫入時間。

就像一切，你的情況將決定是否這將是或多或少高性能的爲您服務。如果你的應用程序是OLTP風格的話，那麼如果你的事務容易發生死鎖，那麼它可能會大大增加性能。