简单的问题？
为什么READ_COMMITTED_SNAPSHOT默认不开启？
我猜是向后兼容性、性能还是两者兼而有之？
[编辑]请注意，我感兴趣的是与 READ_COMMITTED 隔离级别相关的效果，而不是快照隔离级别。
为什么这是一个重大更改，因为它持有更少的锁，并且仍然不读取未提交的行？
【问题讨论】：
标签： sql-server sql-server-2005 isolation-level read-committed-snapshot
默认开启快照会破坏绝大多数应用程序
我不清楚它是否会破坏“绝大多数”应用程序。或者，如果它会以难以识别和/或难以解决的方式破坏许多应用程序。 SQL Server 文档指出READ COMMITTED 和READ COMMITTED SNAPSHOT 都满足READ COMMITTED 的ANSI 定义。 （此处声明：http://msdn.microsoft.com/en-us/library/ms189122.aspx）因此，只要您的代码不依赖于文字 ANSI 要求的行为之外的任何内容，理论上，您会没事的。
一个复杂的问题是 ANSI 规范并没有捕捉到人们通常认为的所有内容，例如脏读、模糊/不可重复读等。在实践中意味着什么。而且，READ COMMITTED SNAPSHOT 下可能发生的异常（ANSI 定义允许）在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 不在，但其他级别已包含在内）。
【讨论】：
两者兼而有之。主要是兼容性。
默认情况下打开快照会破坏绝大多数期望旧的阻塞行为的应用程序。 Snapshot 使得版本存储大量使用 tempdb，它对性能的影响是相当可观的。
【讨论】：
它改变了 Sybase/SQL Server 系列一直以来的默认锁定策略。它会破坏我所有的应用程序，我在商店中知道的所有应用程序，并破坏大量重要数据。
阅读Wikipedia article完全：您希望银行应用程序背后的代码使用这种隔离模型吗？
因此，一般来说，快照 隔离提出了一些问题 保持非平凡的约束 到可能不欣赏的用户身上 无论是潜在的陷阱还是 可能的解决方案。这样做的好处 传输是更好的性能。
与大多数数据库设计一样，这是一种折衷方案。就我而言，我可以处理锁定等待/死锁（罕见）作为更容易和更“开箱即用”数据完整性的代价。我还没有遇到过将快照隔离视为解决方案的问题。
【讨论】：