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 事務時間戳