SQL快照隔离限制

Question

对于我的数据库应用程序，对其某些查询的事务使用快照隔离似乎是解决关键需求之一的完美选择。

我很担心，但是，如何选择快照隔离（我认为必须启用数据库范围）现在咬我们，一旦我们开始得到非常高的音量。快照隔离的成本是多少？它是固定成本，线性还是几何？

如果我是正确的被关注高容量，是否有类似快照可能有更好的整体性能，但需要更多的时间/专长来实现隔离应用程序级功能的战略/模式？

感谢，

杰森

Answer 1

任何人谁是不是已经在锁定和数据库实现的专家，这可能是一个令人惊讶的难以受到周围包裹你的头脑。

我强烈建议由雨果Kornelis（SQL服务器MVP）阅读本series of posts on snapshot isolation。到目前为止，这是我在使用快照时对实用注意事项的最全面分析。

总结的主要问题：

• 当并发事务的特定组合将有可能违反约束（UNIQUE，外键等），SQL Server将回落到旧的方式做事。显然，这对于可靠性很好，但对性能不利。快照并不是万能的，它们不能取代良好的数据库/查询设计和智能锁管理。
• 快照和触发器可能无法在一起玩。如果您使用触发器来保护数据完整性，这是特别危险的，但即使您不这样做，几乎所有的触发器都必须能够识别快照。

根据您编写查询的方式，您甚至可能甚至不需要使用触发器以便以unexpected or inconsistent results结尾。

我不知道成本是固定的还是线性的，尽管它们绝对不是几何的;无论如何，我都知道这有点让人头疼。人们经常谈到它是一种即忘即忘的选择，但事实是，事实并非如此，如果你不知道自己在做什么，最终可能会发生突变（可能不会发现的变化）直到为时已晚！）。

通过各种手段做，如果你确定它不会导致任何其他问题使用它。但是，如果您的任何逻辑不关心脏读（这适用于多数系统中SELECT查询的一半以上），那么使用READ UNCOMMITTED（其确实涉及更多的“专业知识”）会得到更好的结果 - 您必须仔细考虑可能发生什么以及何时发生）。

更新：在应用程序级别的替代

是弹簧想到的只有一个是缓存。有些数据框架可以为你做（NHibernate，EF），在某些情况下，你甚至可能有第三层缓存，比如基于消息输入缓存结果的Web服务，可能基于多个查询的结果。我不会真的称这为“替代”，但我想如果这些是只读查询并且底层数据不会频繁更改，某种形式的缓存将对您的情况有效。当然，设计的考虑因素是，相对于您需要提供服务的数量，您可以承受的缓存数据量有多少;如果系统是大规模并发的，那么这可能不会扩展。

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

Answer 2

快照隔离，就是要更加阅读比其他隔离级别高性能。通过将数据分隔成快照，事务不需要获取行上的锁，这可以防止阻塞和死锁。

但是，它必须将行版本信息写入tempdb数据库。因此，对于每笔交易，都应该预计一些写入时间。

就像一切，你的情况将决定是否这将是或多或少高性能的为您服务。如果你的应用程序是OLTP风格的话，那么如果你的事务容易发生死锁，那么它可能会大大增加性能。