同时使用Serializable和Snapshot隔离级别的影响

Question

使用SNAPSHOT隔离级别来进行读取操作，以保证数据的一致性并避免锁定、阻塞或脏/幻读，同时另一个进程在串行化事务中处理连续的输入数据，是否存在问题？

我们需要读取器（保证只读：Web 数据同步、实时监控视图等）能够读取一致的数据，而不会被阻塞或阻塞更新。我们一直使用 SNAPSHOT，但出现了太多的一致性失败，因此将更新过程切换为 SERIALIZABLE。

我已经阅读了一些关于同时使用不同隔离级别的影响的信息，但还不是很清楚。我已经看过锁兼容矩阵和其他各种信息。这似乎没问题，但我真的很希望从有实际经验的人那里得到一些明智的指导，了解任何主要的陷阱。

在写入 SERIALIZABLE 事务时，使用 SNAPSHOT 隔离级别的读取器是否存在问题？是否会阻塞 SERIALIZABLE 事务？与使用 READ COMMITTED（启用 READ_COMMITTED_SNAPSHOT）相比，使用 SNAPSHOT 是否有优势？

谢谢，非常感谢您的帮助 :-)

- mos

Answer 1

在快照隔离级别下执行的读取操作从版本存储中读取任何已修改的数据。因此，它们仅受到写入的影响。所有隔离级别下的写入行为都是相同的。因此，无论并发事务的隔离级别如何，快照读取的行为方式都是相同的。

将READ_COMMITTED_SNAPSHOT设置为ON使READ COMMITTED作为SNAPSHOT运行。实际上，它就是SNAPSHOT：提供READ_COMMITTED_SNAPSHOT是为了方便应用程序在不进行代码更改的情况下迁移到SNAPSHOT。因此，第一段中所说的所有内容都适用于此情况。

- Remus Rusanu

---

谢谢！是否存在一种情况，使得在SNAPSHOT隔离级别下的读取可能会导致SERIALIZABLE事务阻塞？（起初我想使用NOLOCK提示，但是读了一些评论发现存在风险，因此SNAPSHOT更好） - mos

如果SNAPSHOT事务执行写操作，则它可以阻塞任何事务，包括串行化事务。如果SNAPSHOT事务仅执行读操作，则不会在锁上阻塞任何其他事务。还有其他类型的资源争用（即在其他东西而不是锁上阻塞），但这些都是极端情况，如内存耗尽，而不是普通操作。无论如何，SNAPSHOT读取绝对是您最好的选择。 - Remus Rusanu