为什么默认情况下不打开读提交快照?

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

默认情况下,打开快照会破坏绝大多数应用程序,这些应用程序都期待着旧的、阻塞的行为。快照制作 重的 在版本存储中使用tempdb及其对性能的影响是可以测量的。

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

我不清楚它是否会破坏“绝大多数”的应用程序。或者,如果它将以难以识别和/或难以解决的方式破坏许多应用程序。SQL Server文档声明 READ COMMITTED 和 READ COMMITTED SNAPSHOT 两者都满足ANSI的定义 已提交读取 . (这里声明: http://msdn.microsoft.com/en-us/library/ms189122.aspx )所以,只要您的代码不依赖于任何超出ANSI要求的字面行为,从理论上讲,您就没事了。

一个复杂的问题是,在实际操作中,ANSI规范并没有捕获人们通常认为的脏读、模糊/不可重复读等内容。而且,在以下情况下可能会发生异常(由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 完全地 :是否希望银行应用程序背后的代码使用此隔离模型?

因此,一般来说,快照 孤立使一些问题 保持非平凡约束 用户可能不喜欢 无论是潜在的陷阱还是 可能的解决方案。这个的好处 转移是更好的表现。

像大多数数据库设计一样,这是一个折衷方案。在我的例子中,我可以处理锁定等待/死锁(很少),作为更简单、更“开箱即用”的数据完整性的代价。我还没有遇到一个我认为快照隔离是解决方案的问题。