事务提交延迟在MongoDB 7.0中主要由写关注配置、多数节点可用性、票证竞争或oplog滞后导致；需通过rs.status()排查不可用节点并重配votes/priority，检查serverStatus.queues.execution确认票证耗尽，避免事务内扫描操作，拆分大事务，并验证分片集群中跨分片事务瓶颈。
事务提交延迟在 MongoDB 7.0 中通常不是孤立问题，而是由写关注（write concern）、多数节点可用性、票证竞争或 oplog 滞后共同导致的；直接调高超时参数治标不治本，必须定位根本瓶颈。
检查 majority 写关注是否卡在投票节点上
当副本集里有节点不可用或延迟（如从节点同步滞后），w: "majority" 会等待多数节点确认，但若该节点被配置为 votes: 1 却实际不可达，写操作就会阻塞直到超时（默认 60 秒）。
- 运行
rs.status()查看各成员的stateStr和optime，确认是否有成员处于STARTUP2、RECOVERING或UNKNOWN状态 - 对不可用/延迟的从节点，立即执行
rs.reconfig()将其votes和priority设为0，避免它参与 majority 投票 - 注意：不要仅设
priority: 0，必须同时设votes: 0，否则仍计入 majority 计数
验证 WiredTiger 票证是否耗尽
MongoDB 7.0 默认启用动态票证算法，但若并发写事务激增（尤其在短事务高频提交场景），storageEngineConcurrentWriteTransactions 可能成为瓶颈，表现为 TransactionTooLargeForCache 错误或事务排队延迟。
- 执行
db.serverStatus().queues.execution，检查available字段是否长期接近 0（尤其是write类） - 若
available常低于 10，说明写票证紧张；可临时调高上限（但不超过 128）：db.adminCommand({ setParameter: 1, storageEngineConcurrentWriteTransactions: 96 }) - 注意：该参数是节点级配置，需在每个 mongod 实例上单独设置，且重启后失效；生产环境建议通过配置文件持久化
避免事务内执行非必要操作
7.0 对事务体积更敏感——TransactionTooLargeForCache 错误不再自动重试，且 upsert 在重复键时也不再重试，这两点显著放大低效事务的影响。
- 事务内禁止执行
countDocuments()、distinct()等扫描类操作；改用带索引的精确查询替代 - 批量写入尽量拆分为多个小事务（例如每 100 条一个事务），而非单个大事务；WiredTiger 对单事务修改文档数有限制（默认约 10MB 变更日志）
- 显式指定
readConcern: "local"和writeConcern: { w: 1 }（如果业务允许），绕过 majority 等待和读一致性开销
确认分片集群中跨分片事务未引入额外延迟
跨分片事务需协调器（mongos）与所有相关分片通信，任意一个分片响应慢都会拖慢整个事务提交；而 7.0 的 serverStatus 不直接暴露跨分片事务队列，需间接判断。
- 在 mongos 上执行
db.currentOp({ "secs_running": { "$gt": 5 } })，筛选长时间运行的commitTransaction操作，观察其shard字段是否集中于某一分片 - 检查目标分片的
db.serverStatus().metrics.commands.commitTransaction延迟百分位（如p99），若明显高于其他分片，说明该分片存在 I/O 或锁竞争 - 跨分片事务无法规避多数写关注——即使只写两个分片，也需满足
w: "majority"在每个分片内部达成，因此务必确保所有涉及分片的 PSA 配置健康
真正影响事务提交延迟的，往往不是单个参数调整，而是节点角色配置错误（比如延迟节点仍保留 votes: 1）或事务设计越界（如在事务里做全集合扫描）。7.0 的动态票证机制和严格错误策略，让这些隐患暴露得更快、更直接。
