db.currentOp({ "secs_running": { "$gt": 5 }, "lsid": { "$exists": true } })可快速筛出卡住的事务操作；secs_running高且waitingForLock为false说明执行慢，true则表明锁等待，低值但延迟高需查驱动或网络；system.profile需按lsid+txnNumber聚合分析；explain("executionStats")才能准确定位索引与扫描问题。
用 db.currentOp() 快速筛出卡住的事务操作
事务超时，90% 以上不是事务本身的问题，而是某条 find、update 或 aggregate 在里面拖住了。直接运行：
db.currentOp({ "secs_running": { "$gt": 5 }, "lsid": { "$exists": true } })就能揪出运行超 5 秒、且属于某个事务的操作。重点关注三个字段：
•
secs_running 高 + waitingForLock: false → 真正在执行，比如没索引的 $lookup 或大文档反序列化慢•
waitingForLock: true → 在等锁，说明上游有长事务或写密集操作占着资源，得顺藤摸瓜找 secs_running 最高的那个 op•
secs_running 很低（比如 0.2s），但客户端报超时 → 别在数据库里瞎查，问题大概率在驱动批量提交（如 Go driver 默认 100ms flush）、网络 RTT 高，或事务外的连接建立/认证耗时
从 system.profile 还原完整事务链路
Profiler 不记录 commitTransaction，只记事务内部真实操作，且每条日志不会带 “transaction” 标签。光看单条日志容易误判——你以为是慢 update，其实是事务里第 4 条语句。
必须按 lsid 和 txnNumber 聚合还原：
• 执行：
db.system.profile.find({ "lsid": { "$exists": true }, "txnNumber": { "$exists": true } }).sort({ "ts": 1 })• 用脚本或人工分组，把同一
lsid+txnNumber 的操作串成一条执行流关键指标交叉看：
•
nScannedObjects 远大于 nReturned → 对应的 find 或 update 极可能没走索引，触发 collection scan•
keysExamined 高但 nScannedObjects 低 → 索引扫描范围大（比如查 { ts: { $gt: ... } } 却没加等值条件），实际命中文档少•
docsExamined 明显高于业务预期更新数 → update 条件太宽，或索引因 $regex 前缀通配失效
对可疑语句跑 explain("executionStats") 确认执行计划
system.profile 里的 millis 是命令执行时间，不含网络传输、驱动解析、WiredTiger 日志刷盘等开销。尤其对小文档高频事务，millis 可能才 2ms，端到端却超 1s——这时候瓶颈根本不在执行层。
真正要定位执行层问题，必须回到原始语句手动加 .explain("executionStats")：
• 确认 winningPlan.stage 是 IXSCAN 而非 COLLSCAN
• 检查 executionStats.totalDocsExamined 是否与业务逻辑匹配（比如只该改 1 条，却扫了 5 万条）
• 若用聚合，重点看 $lookup 阶段是否走了 IXSCAN，没走就是左表驱动右表全扫
别信 executionStats.executionTimeMillis 单一数值，它不反映内存排序、磁盘 spill 或 pipeline 阶段间数据搬运开销
别漏掉 maxTimeMS 和驱动层的隐性超时叠加
事务超时往往是多层 timeout 叠加的结果：应用层设了 5s，驱动默认又加了 30s 重试，MongoDB 服务端还配了 defaultMaxTimeMS。一旦某条语句卡在锁等待或慢磁盘上，几层 timeout 就会快速耗尽。
检查点：
• 应用代码里有没有给关键查询显式加 maxTimeMS()？比如 db.collection.find(...).maxTimeMS(2000)
• 驱动配置里有没有开启自动重试（Go driver 的 retryWrites=true）？它会让单次失败操作重试多次，总耗时翻倍
• 运行 db.adminCommand({ getCmdLineOpts: 1 }) 查 defaultMaxTimeMS 是否被全局设为低值（如 1000ms），这会无差别压垮所有未显式设 timeout 的读操作
• db.runCommand({ setParameter: 1, traceAllTransactions: true }) 可临时开启事务元操作追踪，但仅限调试，生产慎用——它会产生大量日志并影响性能
