compass的performance面板不显示事务独立状态，仅提供数据库聚合指标；事务详情需通过currentop、日志或explain等手段下钻分析。
Compass 的 Performance 面板本身不直接显示事务（transaction）的独立状态，它展示的是数据库整体操作层面的聚合指标。如果你在找“某次事务是否卡住、是否提交失败、是否持有锁”，Performance 面板无法满足——你需要切换到 explain、日志或 currentOp 命令。
Performance 面板里哪些指标和事务有关联
虽然没有“事务”标签页，但以下指标异常升高时，往往暗示事务行为异常：
-
opcounters_commit和opcounters_abort：这两个计数器只在启用了副本集且运行 4.0+ 版本的 WiredTiger 引擎时才会上报。Compass 的“操作”图表默认不拆分显示它们，需手动检查/metrics接口或用db.serverStatus().metrics.transactions查看原始值 -
globalLock.activeClients或locks相关曲线：如果“锁等待时间”或“写入锁持有时间”持续偏高，可能是长事务阻塞了其他操作 -
operation latency中的写操作延迟突增：特别是update和delete，若发生在多文档事务中且未加索引，容易拖慢整条事务链 - 连接数
connections_current居高不下 + 活跃操作数低：可能有事务开启后未关闭（比如应用层session.startTransaction()后没调commitTransaction()或abortTransaction()）
真正能查事务状态的地方不是 Performance 面板
Performance 是宏观视图，事务是会话级行为，必须下钻：
- 打开 Shell 标签页，执行：
db.currentOp({ "secs_running": { "$gt": 5 } })—— 找出运行超 5 秒的操作，重点看lsid（会话 ID）、secs_running、microsecs_running和secs_running是否为 0（表示刚启动） - 检查事务字段：
"transaction": { "state": "inProgress", "numOperations": 3 }表示该会话确实在事务中，且已执行 3 个操作 - 在 Compass 的“集合”视图中，对疑似慢查询右键 → “Explain Plan”，确认执行阶段是否含
TRANSACTION上下文（仅限 4.2+），以及是否触发了COLLSCAN导致事务变长 - 如果使用副本集，还需查
db.adminCommand({ replSetGetStatus: 1 })确认主节点是否健康——事务提交依赖主节点写入 oplog
为什么 Performance 面板看不到事务详情
这不是 Compass 的功能缺失，而是 MongoDB 服务端的设计限制：
- 事务状态不通过
serverStatus或top命令暴露给监控接口，Compass 的 Performance 数据全部来自这些标准命令 -
currentOp返回结果默认不包含事务元数据（如隔离级别、start timestamp），除非显式传参{ $all: true } - Compass 2024 年新增的“性能警报”也仅支持
queryLatency、memoryResident等通用指标，无transactionDuration类阈值配置项 - 真正做事务可观测性，得靠日志：
grep -i "transaction" /var/log/mongodb/mongod.log，留意Starting transaction、Aborting transaction、Committing transaction这三类标记
事务不是“开个开关就能看见”的东西，它藏在会话生命周期里。Performance 面板只能告诉你“系统有点堵”，而堵在哪、谁在占道、有没有人忘了熄火——得靠 currentOp、日志和 explain 一层层剥开。别指望图形界面替你读内存里的事务上下文。
