MongoDB事务中readPreference必须为primary，否则报错；因事务需因果一致性，所有读写须在同一主节点执行以保证原子性与隔离性，secondary存在延迟且破坏快照一致性。
事务中 ReadPreference 设为 primary 以外的值会直接失败
MongoDB 事务强制要求所有读写操作落在 primary 节点上，readPreference 必须是 "primary"（或未显式设置，默认即此值）。如果在 session.startTransaction() 前或过程中把 readPreference 改成 "secondary" 或 "nearest"，事务启动会报错：Read preference in a transaction must be primary。
常见错误现象：
- ORM 封装层（如 Mongoose）自动注入了非 primary 的 readPreference
- 全局连接配置里设了
readPreference: 'secondaryPreferred'，但没在事务 session 中覆盖 - 误以为“事务内读可以走从库”来分摊压力，实际不支持
实操建议：
- 显式创建 session 时传入
{ readPreference: { mode: "primary" } }，不依赖默认 - 检查中间件或连接池初始化代码，确保事务相关 session 不被全局 readPreference 污染
- 不要试图在事务中做读扩展——它本就不允许
WriteConcern 设置过松会导致 oplog 写放大被掩盖，但风险剧增
writeConcern 控制写操作在多少节点落盘后才返回成功。事务中若设为 { w: 1 } 或 { w: "majority" }，表面看只是影响延迟，实则深刻影响 oplog 写放大暴露时机与故障面。
为什么容易踩坑：
-
w: 1时 primary 写完就返回，oplog 条目已生成并开始向 secondary 同步；但若 secondary 落后太多，oplog.rs 很快被覆盖，引发同步中断甚至 initial sync -
w: "majority"能缓解 oplog 覆盖风险，但会拉长事务持有时间，间接推高secs_running和numYields，增加锁竞争和 oplog 密度 - 事务提交前，所有 oplog 条目已在内存构造完毕，
writeConcern只决定“何时确认”，不改变“写多少条”
实操建议：
- 生产环境事务必须用
{ w: "majority", wtimeout: 5000 }，避免因单节点延迟导致整个事务假死 - 禁用
{ w: 0 }—— 它跳过 write concern 校验，事务看似快了，但 oplog 丢失风险不可控 - 配合
db.getReplicationInfo()监控oldestTimestamp，比timeDiffHours更准；一旦发现落后 >30 分钟，先查currentOp里长事务，再调优writeConcern
multi:true 的 updateMany 在事务中不会合并 oplog，但 WriteConcern 会影响重放节奏
updateMany 匹配 N 条文档，在事务中仍生成 N 条独立 oplog 记录，这点和普通命令完全一致。区别在于：writeConcern 会改变这 N 条 oplog 被 secondary 重放的节奏和容错能力。
典型场景：
- 批量状态更新：1000 个订单从
pending→processing，用updateMany({ status: "pending" }, { $set: { status: "processing" } }) - 若
writeConcern: { w: 1 }，primary 写完 1000 条 oplog 就返回，secondary 可能只同步了前 200 条就断连 - 若
writeConcern: { w: "majority" }，primary 会等 majority 节点都收到全部 1000 条 oplog 后才 commit，重放链更完整，但事务窗口变长
关键事实：
- oplog 条目数 = 匹配文档数 × 操作类型数（
updateOne算 1 条，updateMany算 N 条） - 事务不压缩、不 dedup、不 batch oplog；
bulkWrite同理，每个updateOne都单独记日志 - 真正影响 oplog 写放大的不是
writeConcern本身，而是它迫使事务等待更久，让其他并发写入也挤进同一段 oplog 窗口
ReadConcern 选 local 还是 majority？取决于你是否容忍 stale read
readConcern 控制事务内读操作能看到哪些数据版本。选 "local"（默认）还是 "majority"，直接决定 oplog 压力分布模式。
差异本质：
-
readConcern: "local"：读当前节点最新已提交数据，不等 majority 落盘。oplog 生成不受读影响，但可能读到之后被回滚的写（极少见，仅当 primary 故障降级时） -
readConcern: "majority"：只读已被 majority 节点确认的数据。这意味着事务内每次读，都隐式等待对应写入完成 majority 复制——变相延长事务生命周期，加剧 oplog 密集写入
实操判断点：
- 业务能接受「读到稍旧但确定不会回滚」的数据？选
"majority"，适合金融类强一致性场景 - 业务更看重低延迟、高吞吐，且写入本身已用
w: "majority"保障？保持"local"即可，oplog 压力最小 - 切勿混用：
readConcern: "majority"+writeConcern: { w: 1 }是危险组合，读等待多数派，写却只落盘一个节点
最容易被忽略的一点：事务中 readConcern 和 writeConcern 是解耦配置，但它们共同决定了 oplog 的“生产节奏”与“消费节奏”。调优必须两者一起看，不能只盯 writeConcern。
