MongoDB 4.0+ 副本集或分片集群使用 WiredTiger 引擎才支持事务，db.currentOp() 需加 {"lsid": {"$exists": true}} 等条件过滤；事务未提交会导致操作卡住，应通过 db.killSession() 而非 db.killOp() 清理。

db.currentOp() 查不到事务？先确认 MongoDB 版本和事务启用状态

MongoDB 4.0+ 才支持多文档事务，且仅在副本集或分片集群的 WiredTiger 存储引擎下生效。单机模式（standalone）默认不开启事务支持，db.currentOp() 也不会返回事务相关信息。

• 检查版本：db.version()，低于 4.0 直接不支持
• 确认部署模式：rs.status() 能成功执行才说明是副本集；单机运行 mongod 无 rs.initiate() 则事务不可用
• 验证存储引擎：db.serverStatus().storageEngine.name 必须返回 wiredTiger

真正能查到事务的命令是 db.currentOp({ "secs_running": { "$gt": 0 }, "active": true })

db.currentOp() 默认只显示活跃操作，但事务本身不会直接标为 “transaction”，而是通过关联字段识别。关键不是找关键词，而是过滤出带事务上下文的操作：

• 事务中的操作会带有 lsid（逻辑会话 ID）和 txnNumber 字段
• 必须加条件过滤，否则会被大量普通查询淹没：

  db.currentOp({
  "secs_running": { "$gt": 0 },
  "active": true,
  "lsid": { "$exists": true }
  })

• 如果想进一步聚焦写事务，可追加："secs_running": { "$gt": 5 }（避免刚启动的瞬时事务干扰）

为什么 find() 或 getMore 操作看起来像“卡住”，其实是事务没提交

事务未提交（session.commitTransaction()）或未中止（session.abortTransaction()）时，相关操作会持续占用会话、持有锁，并出现在 currentOp 中。常见现象包括：

• 应用日志里反复出现 find 或 update 操作，secs_running 持续增长
• 其他客户端对同一集合的写入被阻塞，db.currentOp({ "waitingForLock": true }) 可能返回非空结果
• 事务会话（lsid）在多次 currentOp 查询中保持不变，但 txnNumber 不变 —— 表示它还没结束

这时不要 kill op，先尝试从应用侧触发 commit 或 abort；硬杀可能留下孤儿会话。

db.killOp() 杀不掉事务？因为要 kill 会话，不是操作

db.killOp() 只终止具体操作（opid），但事务生命周期由会话（session）管理。一个会话里可以有多个操作，kill 掉其中一个，事务仍处于 active 状态。

• 正确做法是定位 lsid，然后在 mongosh 中调用：db.killSession({ "id": "<session_id>" })</session_id>
• lsid 是 BSON 对象，实际使用时需展开，例如：db.killSession({ "id": UUID("a1b2c3d4-...") })
• 注意：MongoDB 4.2+ 才支持 killSession；4.0 只能靠重启节点或等待超时（默认 60 分钟）

事务的活跃状态依赖会话保活机制，网络抖动或应用崩溃后未显式关闭 session，就容易堆积。这点比普通查询更隐蔽，也更难清理。