为什么默认情况下未启用 READ_COMMITTED_SNAPSHOT？
简单的问题？
为什么READ_COMMITTED_SNAPSHOT默认情况下未启用？
我猜测要么是向后兼容性，要么是性能，或者两者兼而有之？
[编辑] 请注意，我感兴趣的是与 READ_COMMITTED 隔离级别相关的效果，而不是快照隔离级别。
为什么这是一个重大更改，因为它持有较少的锁，并且仍然不读取未提交的行？
Simple question?
Why is READ_COMMITTED_SNAPSHOT not on by default?
I'm guessing either backwards compatibility, performance, or both?
[Edit] Note that I'm interested in the effect relating to the READ_COMMITTED isolation level, and not the snapshot isolation level.
Why would this be a breaking-change, as it holds less locks, and still doesn't read non-committed rows?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我不清楚它是否会破坏“绝大多数”应用程序。或者，它是否会以难以识别和/或难以解决的方式破坏许多应用程序。 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-潜在-危险-of-the-read-commited-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在撰写本文时还不存在，但其他级别已包含在其中）。It is unclear to me if it will break the "vast majority" of applications. Or, if it will break many applications in ways that are hard to identify and/or hard to work around. The SQL Server documentation states that
READ COMMITTEDandREAD COMMITTED SNAPSHOTboth satisfy the ANSI definition ofREAD COMMITTED. (Stated here: http://msdn.microsoft.com/en-us/library/ms189122.aspx) So, as long as your code does not rely on anything beyond the literal ANSI-required behavior, in theory, you will be okay.A complication is that the ANSI specification doesn't capture everything that people commonly think things like dirty read, fuzzy/non-repeatable read, etc. mean in practice. And, there are anomalies (permitted by the ANSI definitions) that can occur under
READ COMMITTED SNAPSHOTthat cannot occur underREAD COMMITTED. For an example, see http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/.Also see http://social.msdn.microsoft.com/Forums/en-US/sqldatabaseengine/thread/d1b3d46e-2642-4bc7-a68a-0e4b8da1ca1b.
For deep information on the differences between the isolation levels, start with http://www.cs.umb.edu/cs734/CritiqueANSI_Iso.pdf (
READ_COMMITTED_SNAPSHOTwas not around when this paper was written, but the other levels are covered by it).两个都。主要是兼容性。
默认情况下打开快照会破坏绝大多数期望旧的阻塞行为的应用程序。快照大量使用tempdb作为版本存储，它对性能的影响是相当可衡量的。
Both. Mostly compatibility.
Turning snapshot on by default would break the vast majority of applications that expect the old, blocking, behavior. Snapshot makes heavy use of tempdb for the version store and its impact on performance is quite measurable.
它改变了 Sybase/SQL Server 系列一直以来的默认锁定策略。它会破坏我所有的应用程序，我在我的商店中知道的所有应用程序，并损坏许多重要数据。
阅读维基百科文章 完全：您想要您的银行应用程序要使用这种隔离模型吗？
与大多数数据库设计一样，这是一种折衷方案。就我而言，我可以处理锁定等待/死锁（罕见），作为更轻松、更“开箱即用”的数据完整性的代价。我还没有遇到过将快照隔离视为解决方案的问题。
It changes the default locking strategy from how the Sybase/SQL Server family have worked forever. It'd break all my applications, all the application I know of at my shop, and corrupt a lot of important data.
Read the Wikipedia article completely: do you want the code behind your banking app to use this isolation model?
It's a compromise like most database designs. In my case, I can deal with the locking waits/deadlocks (rare) as a price for easier and more "out of the box" data integrity. I've yet to come across a problem or issue where I see snapshot isolation as a solution.