为什么READ_COMMITTED_SNAPSHOT默认不启用？

Question

简单的问题？

为什么READ_COMMITTED_SNAPSHOT默认情况下不启用？

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

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

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

Answer 1

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

我不清楚它是否会打破"绝大多数"应用程序.或者,如果它会以难以识别和/或难以解决的方式打破许多应用程序.SQL Server文档声明READ COMMITTED并且READ COMMITTED SNAPSHOT两者都满足ANSI的定义READ COMMITTED.(在此处说明:http://msdn.microsoft.com/en-us/library/ms189122.aspx)因此,只要您的代码不依赖于文字ANSI所要求的行为之外的任何东西,理论上,您将是好的.

一个复杂的问题是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://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文章 ：您是否希望银行应用程序背后的代码使用此隔离模型？

因此，通常，快照隔离给用户带来了一些维护非平凡约束的问题，用户可能不理解潜在的陷阱或可能的解决方案。这种转移的好处是更好的性能。

像大多数数据库设计一样，这是一个折衷方案。就我而言，我可以将锁定等待/死锁（稀有）作为价格来处理，以实现更轻松，更“开箱即用”的数据完整性。我还没有遇到将快照隔离作为解决方案的问题。