问为什么默认情况下READ_COMMITTED_SNAPSHOT没有打开？

EN

两者都有。主要是兼容性。

默认情况下打开快照将破坏绝大多数期望旧的、阻塞的行为的应用程序。快照使大量使用版本存储的临时数据库，其对性能的影响是相当明显的。

在默认情况下打开快照会中断绝大多数应用程序

我还不清楚它是否会打破“绝大多数”的申请。或者，它是否会以难以识别和/或难以解决的方式破坏许多应用程序。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还不在，但其他级别都在本文中介绍)。

它改变了Sybase/SQL Server系列一直以来的默认锁定策略。它会破坏我所有的应用程序，我在我的商店里知道的所有应用程序，并破坏许多重要的数据。

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

因此，一般而言，快照隔离将维护非平凡约束的一些问题放在用户身上，用户可能不会意识到潜在的陷阱或可能的解决方案。这种传输的好处是性能更好。

与大多数数据库设计一样，这也是一种折衷方案。在我的例子中，我可以处理锁等待/死锁(罕见)，作为更容易和更“开箱即用”的数据完整性的代价。我还没有遇到过将快照隔离作为解决方案的问题或问题。