Snapshot 隔离和 Row Version的工作模式
当启用Snapshot隔离级别时，每一个更新数据的操作都会在tempdb中存储该行的原始副本，术语叫作行版本（RowVersion），SQL Server为每个行版本添加事务的TSN，该TSN能够唯一标识更新操作所在的事务。读操作在读数据时，按照以下顺序进行：
创建一个新的事务，为其分配TSN，一个唯一，递增的序号；
snapshot事务从数据表中读取数据行，从tempdb中读取行版本（row version），该行版本的TSN最接近当前事务的TSN，但比当前事务的TSN小；
在创建Snapshot时，从已提交的事务中获取行版本数据，如果行版本数据标识的事务尚未提交，那么从更早的事务中获取已提交更新的数据；
事务从tempdb中读取行版本数据，事务不会看到新插入的数据，因为插入数据的TSN比当前事务的TSN大；
事务能够看到被其他事务删除的数据，前提是删除数据的事务的TSN比当前事务的TSN大，这是因为其他事务将行版本保存到tempdb中，当前事务从tempdb中读取行版本数据；
4.0 引入事务之后，事务的提交由应用程序控制，
可能出现一个事务修改很多，并且很长时间不提交，
这会给 WT cache evict 造成很大的影响，
如果 大量内存无法 evict ，最终就会进入 cache stuck 状态。
为了尽量减小 WT cache 压力，MongoDB 4.0 事务功能有一些限制，但事务资源占用超过一定阈值时，会自动 abort 来释放资源。规则包括
事务的生命周期不能超过 transactionLifetimeLimitSeconds （默认60s），该配置可在线修改
事务修改的文档数不能超过 1000 ，不可修改
事务修改产生的 oplog 不能超过 16mb，这个主要是 MongoDB 文档大小的限制， oplog 也是一个普通的文档，也必须遵守这个约束。
SQL TSN = MDB 事务时间戳