MongoDB 6.0/7.0中如何借助索引分析器优化慢查询？

作者：袖梨 2026-07-07

MongoDB 6.0/7.0 中不存在独立的“索引分析器”，需组合使用 db.setProfilingLevel() 开启慢查询捕获、explain("executionStats") 分析执行计划、$indexStats 识别低效索引，并严格遵循等值→范围→排序的联合索引字段顺序。

直接结论：MongoDB 6.0/7.0 中没有叫“索引分析器”的独立组件；你真正要用的是 db.setProfilingLevel() + explain() + $indexStats 这套组合，缺一不可。

Profiler 是唯一能告诉你“哪条查询慢、为什么慢”的入口。6.0/7.0 默认关闭，必须手动开启，且级别选错就等于白开：

db.setProfilingLevel(1, { slowms: 50 }) 最常用：只记录 ≥50ms 的操作，写入 system.profile 集合，对线上影响可控
db.setProfilingLevel(2) 别在生产环境用：所有操作都记，system.profile 很快撑满（默认仅 1MB），还会拖慢写入
配置文件里永久生效要写成：operationProfiling.mode: "slowOp" + operationProfiling.slowOpThresholdMs: 50，不是 slowms
执行后务必验证：db.getProfilingStatus() 返回 { "was": 1, "slowms": 50, ... } 才算生效

光看 system.profile 里的 millis 和 ns 不够——它不告诉你用了哪个索引、扫了多少文档。必须对慢查询语句补上 explain("executionStats")：

重点盯 executionStats.executionStages.stage：要是 "COLLSCAN" 就说明完全没走索引
看 executionStats.nReturned 和 executionStats.totalDocsExamined：如果后者远大于前者（比如 10万 vs 10），大概率是索引没覆盖查询字段或顺序不对
注意 executionStats.executionStages.inputStage.keyPattern：确认实际命中的是你预期的那个索引名，而不是 company_id_hashed 这种哈希索引——它对范围查询无效
6.0+ 支持 explain("allPlansExecution")，但别滥用：会真实执行所有候选计划，可能锁表或加重负载

建一堆索引却不清理，写性能会肉眼可见变差。6.0/7.0 用 $indexStats 聚合阶段查真实使用频率：

db.collection.aggregate([ { $indexStats: {} }, { $sort: { "accesses.ops": 1 } } ]) 直接按访问次数升序排，底部就是“僵尸索引”
字段 accesses.ops 是自 MongoDB 3.2 起统计的命中次数，为 0 且存在半年以上，基本可删
特别注意 keyPattern 重复的索引：比如已有 {a:1,b:1}，又建了 {a:1,b:1,c:1}，前者大概率冗余
删除前先确认：db.collection.getIndexes() 检查是否有 hint() 或应用层硬编码依赖该索引名

很多慢查询根源不在有没有索引，而在字段顺序。6.0/7.0 的查询优化器仍严格遵循“等值 → 范围 → 排序”原则：

查询条件是 { company_id: 13272, create_time: { $gte: ..., $lte: ... } }，索引必须是 { company_id: 1, create_time: 1 }，反过来就失效
如果还有 sort({ status: 1 })，理想索引是 { company_id: 1, create_time: 1, status: 1 }，把排序字段塞到最后
哈希索引（"hashed"）只适合等值查询，$gte/$in 等一律绕过，别把它和范围字段混建联合索引
建完立刻验证：db.collection.find(...).explain("executionStats") 确认 stage 变成 "IXSCAN" 且 totalDocsExamined ≈ nReturned