db.currentop() 查不到事务是因为 mongodb 未启用事务支持，需同时满足版本≥4.0、运行于副本集或分片集群、存储引擎为 wiredtiger；事务需通过 lsid 等字段识别，而非 transaction 字段。
db.currentOp() 为什么查不到事务？先确认基础条件
查不到活跃事务，大概率不是命令写错，而是 MongoDB 根本没启用事务支持。必须同时满足三个条件：
-
db.version()返回4.0+（低于 4.0 直接不支持） - 运行在副本集（
rs.status()能返回结果）或分片集群，单机模式（standalone）默认不支持事务 - 存储引擎是
wiredTiger（db.serverStatus().storageEngine.name必须等于"wiredTiger"）
这三个缺一不可。哪怕只差一个，db.currentOp() 就不会返回任何带 lsid 或 txnNumber 的操作——因为事务根本没启动。
真正能过滤出事务的 db.currentOp() 查询条件
事务本身不是一种独立的 op 类型，它藏在普通操作字段里。不能靠 "transaction": true 这种字段去匹配，要靠会话上下文识别：
- 必须加
{"lsid": {"$exists": true}}—— 所有事务操作都绑定逻辑会话 ID - 建议加
{"secs_running": {"$gt": 5}}—— 排除刚开启、瞬时完成的事务干扰 - 可选加
{"active": true}—— 只看仍在执行中的事务，避免已提交/中止但尚未清理的残留
完整命令示例：db.currentOp({ "secs_running": { "$gt": 5 }, "active": true, "lsid": { "$exists": true } })
返回结果里重点看 lsid、txnNumber、secs_running 和 ns 字段，它们共同构成事务的唯一标识和上下文。
事务卡住时，别用 db.killOp()，要用 db.killSession()
看到某个事务 secs_running 持续上涨，第一反应不是杀 opid，因为：
-
db.killOp(opid)只终止当前操作，但会话（lsid）还在，事务状态仍是inProgress - 事务锁不会释放，其他操作继续被阻塞，
waitingForLock: true可能蔓延 - 正确做法是提取
lsid值（注意它是 BSON 对象，不是字符串），然后调用：db.killSession({ "id": { "id": UUID("...") } })（MongoDB 4.2+）或db.killSession({ "id": BinData(4, "...") })（旧版本）
硬杀前务必确认该会话无业务依赖——比如应用层正在重试 commit，贸然 kill 可能导致数据不一致。
Compass Performance 面板看不到事务详情，这不是 bug
Compass 的 Performance 面板展示的是聚合指标（如 opcounters_commit、锁等待时间），它不解析 currentOp 结果，也不暴露会话级事务状态。指望它显示“事务 A 正在阻塞集合 B”是徒劳的。
真正有用的线索藏在这些地方：
-
db.serverStatus().metrics.transactions—— 查总提交/中止数、当前活跃事务数 -
db.currentOp({ "waitingForLock": true })—— 找出被阻塞方，再顺藤摸瓜定位持有锁的事务 - 对疑似慢操作右键 → “Explain Plan”，看执行计划里是否有
TRANSACTION上下文（4.2+）及是否触发COLLSCAN
事务是会话级行为，监控必须下钻到 currentOp 或日志层面，宏观面板只能当辅助预警信号用。
