简单的问题？
为什么READ_COMMITTED_SNAPSHOT默认不开启？
我猜是向后兼容性、性能还是两者兼而有之？
[编辑]请注意，我对与 READ_COMMITTED 隔离级别相关的效果感兴趣，而不是快照隔离级别。
为什么这是一个重大更改，因为它拥有更少的锁，并且仍然不读取未提交的行？
问问题
9370 次
3 回答
19
默认开启快照会破坏绝大多数应用程序
我不清楚它是否会破坏“绝大多数”应用程序。或者，如果它会以难以识别和/或难以解决的方式破坏许多应用程序。SQL Server 文档指出，READ COMMITTED两者READ COMMITTED SNAPSHOT都满足READ COMMITTED. （此处说明：http: //msdn.microsoft.com/en-us/library/ms189122.aspx）因此，只要您的代码不依赖于文字 ANSI 所需行为之外的任何内容，理论上，您将好的。
一个复杂的问题是，ANSI 规范并没有捕捉到人们通常认为的脏读、模糊/不可重复读等在实践中的含义。而且，READ COMMITTED SNAPSHOT在READ COMMITTED. 例如，请参阅http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/。
有关隔离级别之间差异的深入信息，请从http://www.cs.umb.edu/cs734/CritiqueANSI_Iso.pdf开始（READ_COMMITTED_SNAPSHOT在撰写本文时不存在，但其他级别已包含在其中）。
于 2009-09-02T11:00:51.060 回答
17
两个都。主要是兼容性。
默认情况下打开快照会破坏绝大多数期望旧的阻塞行为的应用程序。Snapshot大量使用 tempdb 作为版本存储，它对性能的影响是可以衡量的。
于 2009-09-01T16:35:40.467 回答
5
它改变了 Sybase/SQL Server 系列一直以来的默认锁定策略。它会破坏我所有的应用程序，我在商店中知道的所有应用程序，并破坏许多重要数据。
完整阅读Wikipedia 文章 ：您希望银行应用程序背后的代码使用这种隔离模型吗？
因此，一般来说，快照隔离将一些维护重要约束的问题交给了用户，他们可能既不了解潜在的陷阱，也不了解可能的解决方案。这种转移的好处是更好的性能。
与大多数数据库设计一样，这是一种折衷方案。就我而言，我可以处理锁定等待/死锁（罕见）作为更容易和更“开箱即用”数据完整性的代价。我还没有遇到过将快照隔离视为解决方案的问题。
于 2009-09-01T17:06:25.430 回答