mongodb 5.0 快照读性能提升源于 wiredtiger 对 snapshot isolation 的轻量实现，事务内读不加锁、不阻塞写，但需全程持有快照；关键在缩短快照滞留时间与降低资源开销。
MongoDB 5.0 的快照读事务性能更高，不是因为隔离级别变了，而是 WiredTiger 引擎对 snapshot isolation 的支撑更稳、更轻量——事务内读不额外加锁、不触发写阻塞，但代价是快照必须全程持有，所以性能提升的关键在于「减少快照滞留时间」和「降低快照依赖的资源开销」。
事务内快照读是默认行为，无需设 readConcern: "snapshot"
从 4.0 开始，只要在 session.startTransaction() 内发起的 find、count、aggregate，WiredTiger 就自动基于 MVCC 提供快照视图。你显式写 readConcern: "snapshot" 不但无效，还会被忽略（驱动层静默丢弃）。
常见错误是照搬 SQL 习惯，在事务里手动加：collection.find({ x: 1 }, { readConcern: "snapshot" }) → 实际没用，还可能误导后续维护者以为“这是某种特殊隔离”。
5.0 对窗口函数的聚合读支持更安全，但不改变事务语义
5.0 允许在事务内执行含 $window 的只读聚合，且优化器能下推 $project、更好利用索引，避免全表扫描拖长快照生命周期。
但注意三点：
• $window 计算本身不记 oplog，也不参与原子性 —— 即使整个事务回滚，窗口结果也不会撤销
• 它仍走事务快照，所以如果聚合扫描大量文档，快照保留时间会拉长，WiredTiger 版本链膨胀风险仍在
• 若聚合中混入写操作（如 $out 或 $merge），MongoDB 直接报错：Write operations are not allowed in transactions with aggregation pipelines
真正影响性能的是快照持有时间，不是读操作本身
慢的从来不是「读」，而是「读让快照无法释放」。一个 findOne() 在事务里执行 10ms，但若它导致事务整体运行 5 秒，那 WiredTiger 就得为这 5 秒内所有写入保留旧版本数据。
所以关键优化点是：
• 把不参与一致性判断的读全部移出事务（比如查配置、查用户昵称、统计监控指标）
• 避免在事务内做 bulkWrite(..., { upsert: true }) —— 它隐式触发一次查询，等价于多一次快照读
• 用 transactionLifetimeLimitSeconds 主动限制最长 30 秒（比默认 60 秒更激进），倒逼业务拆分逻辑
• 分片集群中，commitTransaction 默认等待 w: "majority" 确认，5.0 支持设 j: false 缩短返回延迟，但要注意崩溃丢失风险
最容易被忽略的是：事务外的 readConcern: "snapshot" 在 5.0 虽然可用，但它和事务内快照不是同一套机制——前者依赖 oplog 截断点，后者绑定 session 时间戳。混用时若没校准时间窗口，可能读到“比事务内还旧”的快照。
