SQL Server 的 READ COMMITTED SNAPSHOT 与 SNAPSHOT

Question

我正在研究 SQL ServerREAD COMMITTED SNAPSHOT和SNAPSHOT隔离级别之间的差异，并发现以下资源：

选择基于行版本控制的隔离级别

对于大多数应用程序，由于以下原因，建议使用行版本控制读取提交隔离而不是快照隔离：

• 与快照隔离相比，它消耗的 tempdb 空间更少。

• 快照隔离容易受到更新冲突的影响，这些冲突不适用于使用行版本控制的已提交读隔离。当一个在快照隔离下运行的事务读取数据然后被另一个事务修改时，快照事务对相同数据的更新会导致更新冲突，事务终止并回滚。这不是使用行版本控制的已提交读隔离的问题。

我对这些主题有些陌生，但我似乎无法理解上面链接中的两个要点。

1. 为什么这些模式的 tempdb 空间会不同？一个存储比另一个更精细的版本控制吗？

2. 为什么快照隔离更容易受到更新冲突的影响？

Answer 1

1. READ COMMITTED SNAPSHOT在每个语句之后使用一个新快照。这意味着保持活动的行版本较少。（您从文档中引用的声明有点误导，因为它表明这总是正确的 - 只有在长时间运行的SNAPSHOT事务的情况下才正确。）快照行版本是在写入时创建的。读取不会影响放入 tempdb 的内容。作家不可能预见到将来会进行什么阅读。读者只影响可以清除的内容。
2. 当一个SNAPSHOT事务T1写入T2在T1开始和T1尝试写入之间的时间内被另一个事务修改的行时，该语句将失败并出现更新冲突错误。这是一个乐观并发模型。WithREAD COMMITTED SNAPSHOT T1将等待T2释放行上的 X 锁并正常继续。