需先确认活跃超时事务，再验证其是否持续持有写锁并触发wiredtiger索引重复写入——事务不释放旧版本快照致b-tree节点无法回收，引发磁盘增长与查询延迟升高。
排查MongoDB 6.0中因长事务未提交导致的索引膨胀，需先确认是否存在活跃超时事务，再验证其是否持续持有写锁并触发WiredTiger内部索引结构重复写入——这类事务不释放旧版本文档快照，使索引B-tree节点无法合并回收，最终引发磁盘空间异常增长和查询延迟升高。
定位仍在运行的长事务
启动mongosh连接到目标副本集主节点，执行：
db.currentOp({ "secs_running": { "$gt": 30 }, "active": true, "type": "txn" })
重点筛查secs_running > 30秒且type为txn的记录；若该事务的client字段指向某个应用IP+端口，但对应服务日志已无新请求痕迹，说明应用层可能崩溃或网络中断却未主动rollback。
不要直接kill所有长事务——【误杀正在写入关键业务数据的事务会导致数据不一致】。先用db.killOp(
检查WiredTiger索引文件实际增长情况
登录MongoDB所在服务器，进入数据目录（默认/var/lib/mongodb）→ 执行ls -lh WiredTiger* | grep -E "(wt$|index)"
查看以WiredTigerIndex开头的文件大小，若单个文件超过500MB且近24小时持续增大，而集合文档数无明显增长，基本可判定索引膨胀已发生。
运行lsof -p $(pgrep mongod) | grep wt | wc -l，若结果远大于正常值（通常
分析system.profile确认索引写放大
第一步：确认profiling已开启且生效
db.getProfilingStatus() → 若level为0，立即执行db.setProfilingLevel(1, { slowms: 50 })
第二步：筛选最近高频更新但未提交的集合
db.system.profile.find({ "ns": /your_collection_name/, "millis": { "$gt": 100 } }).sort({ "ts": -1 }).limit(5)
第三步：检查docsExamined与nReturned比值
若某update或findAndModify操作中docsExamined ≥ 10 × nReturned，且该操作属于长事务链中的子操作，说明索引被迫反复扫描旧版本文档，加剧B-tree分裂。
注意：profile中出现大量“writeConflicts”字段非空的记录，是索引膨胀的强信号——WiredTiger因版本冲突不断重试写入，导致同一索引键被多次写入不同快照。
