sql-server-2005 - SQL 快照隔离限制

Question

对于我的数据库应用程序，对其某些查询事务采用快照隔离似乎非常适合解决关键要求之一。

不过，我担心，一旦我们开始获得非常高的容量，现在选择快照隔离(我认为必须在数据库范围内启用)将会给我们带来怎样的困扰。快照隔离的成本是多少？它是固定成本、线性成本还是几何成本？

如果我对高容量的担忧是正确的，那么是否有类似于快照隔离的应用程序级功能的策略/模式，可能具有更好的整体性能，但需要更多的时间/专业知识来实现​​？

谢谢

杰森

Answer 1

对于任何还不是锁定和数据库实现专家的人来说，这可能是一个令人惊讶的难以理解的主题。

我强烈推荐阅读这篇文章 series of posts on snapshot isolation作者:Hugo Kornelis(SQL Server MVP)。到目前为止，这是我所见过的关于使用快照时的实际注意事项的最完整的分析。

总结主要问题:

• 当并发事务的特定组合可能违反约束(UNIQUE、FOREIGN KEY 等)时，SQL Server 将回退到旧的处理方式。显然，这对可靠性有好处，但对性能却不利。快照不是万能药，它们不能替代良好的数据库/查询设计和智能锁管理。
• 快照和触发器可能无法很好地协同工作。如果您使用触发器来保护数据完整性，这尤其危险，但即使您不这样做，几乎所有触发器都必须具有快照感知功能。

根据您编写查询的方式，您甚至可能不需要使用触发器即可得到 unexpected or inconsistent results .

我不知道成本是固定的还是线性的，尽管它们绝对不是几何的；我确实知道无论如何这都有点令人头痛。人们经常将其视为“一劳永逸”的选项，但事实是，事实并非如此，如果您不知道自己在做什么，最终可能会做出重大更改(您可能不会发现这些更改)直到为时已晚!)。

如果您确定它不会导致任何其他问题，请务必使用它。但是，如果您的任何逻辑不关心脏读(这适用于许多系统中超过一半的 SELECT 查询)，那么使用 READ UNCOMMITTED 将会获得更好的结果。 (这确实涉及更多“专业知识” - 您必须非常仔细地考虑可能发生什么以及何时发生)。

更新:关于应用程序级替代方案

唯一想到的是缓存。某些数据框架可以为您执行此操作(NHibernate、EF)，在某些情况下您甚至可能拥有第三层缓存，例如基于消息输入缓存结果的 Web 服务，这些结果可能基于多个查询。我不会真正称其为“替代方案”，但我想如果这些是只读查询并且底层数据不经常更改，某种形式的缓存在您的情况下将是有效的。当然，设计时要考虑的是，相对于您需要服务的数据量，您可以缓存多少数据；如果系统是大规模并发的，那么这可能无法扩展。

除此之外，我个人不会选择尝试实现我自己的应用程序级事务“层”。也许有些人已经这样做了，但我认为我有限的经验无法与数百或数千名在 DBMS 上工作了 20 年的最聪明的设计师竞争。