为什么READ_COMMITTED_SNAPSHOT默认不启用？

Question

简单的问题？

为什么READ_COMMITTED_SNAPSHOT默认不启用？

我猜是向后兼容性，性能还是两者兼而有之？

[编辑] 请注意，我对与READ_COMMITTED隔离级别相关的效果感兴趣，而不是快照隔离级别。

为什么这会是一个突破性的变化，因为它拥有更少的锁，并且仍然不会读取未提交的行？

Answer 1

  

默认情况下打开快照会破坏绝大多数应用程序

我不清楚它是否会破坏“绝大多数”应用程序。或者，如果它会以难以识别和/或难以解决的方式打破许多应用程序。 SQL Server文档指出READ COMMITTED和READ COMMITTED SNAPSHOT都满足READ COMMITTED的ANSI定义。 （在此处陈述：http://msdn.microsoft.com/en-us/library/ms189122.aspx）因此，只要您的代码不依赖于文字ANSI所要求的行为之外的任何东西，理论上，您就可以了。

一个复杂的问题是ANSI规范没有捕获人们通常认为的东西，如脏读，模糊/不可重复读等等。并且，READ COMMITTED SNAPSHOT下可能发生的READ COMMITTED下无法发生的异常（ANSI定义允许）。有关示例，请参阅http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/。

另见http://social.msdn.microsoft.com/Forums/en-US/sqldatabaseengine/thread/d1b3d46e-2642-4bc7-a68a-0e4b8da1ca1b。

有关隔离级别之间差异的深层信息，请从http://www.cs.umb.edu/cs734/CritiqueANSI_Iso.pdf开始（READ_COMMITTED_SNAPSHOT在写这篇论文时并不存在，但其他级别也包括在内。）

Answer 2

两者。主要是兼容性。

默认情况下打开快照会破坏绝大多数期望旧的阻塞行为的应用程序。快照对版本存储使用tempdb 重度，并且它对性能的影响是可以衡量的。

Answer 3

它更改了Sybase / SQL Server系列永久工作方式的默认锁定策略。它打破了我的所有应用程序，我在商店里知道的所有应用程序，并破坏了许多重要数据。

完全阅读Wikipedia article ：您是否希望银行应用程序背后的代码使用此隔离模型？

  

因此，一般情况下，快照   隔离提出了一些问题   保持非平凡的约束   对用户，可能不欣赏   无论是潜在的陷阱还是潜在的陷阱   可能的解决方案。这个好处   转移是更好的表现。

这是大多数数据库设计的妥协。在我的情况下，我可以处理锁定等待/死锁（罕见）作为更容易和更“开箱即用”数据完整性的代价。我还没有遇到过将快照隔离视为解决方案的问题或问题。