MongoDB 6.0/7.0用索引分析器优化慢查询方法

好的，没问题。作为一名在数据库运维领域深耕十余年的DBA，我将这篇实战经验重新梳理，让它更贴近一线运维笔记的风格。 先给出结论：MongoDB 6.0与7.0中并不存在一个名为“索引分析器”的独立按钮。要高效优化慢查询，真正需要掌握的是 `db.setProfilingLevel()`、`explain()` 和 `$indexStats` 这套组合拳，三者缺一不可。 ### 第一步：利用 `db.setProfilingLevel()` 精准捕获慢查询元凶 Profile功能是识别“哪条查询慢、为什么慢”的唯一入口，但默认处于关闭状态，需要手动开启。级别选择不当等于白费功夫。 * **推荐做法**：执行 `db.setProfilingLevel(1, { slowms: 50 })`，仅记录执行时间超过50毫秒的操作至 `system.profile` 集合，对线上业务影响可控。 * **生产环境严禁**使用 `db.setProfilingLevel(2)`，因为这会记录所有操作，导致默认容量仅为1MB的 `system.profile` 集合迅速被写满，写入性能也会显著下降。 * **永久生效**需在配置文件中设置：`operationProfiling.mode: "slowOp"` 和 `operationProfiling.slowOpThresholdMs: 50`，注意参数名为 `slowOpThresholdMs`，而非 `slowms`。 * **验证配置**：执行 `db.getProfilingStatus()`，若返回结果包含 `{ "was": 1, "slowms": 50, ... }`，则代表配置已生效。 ### 第二步：使用 `explain("executionStats")` 深度分析查询执行计划 仅查看 `system.profile` 中的 `millis` 和 `ns` 字段不足以定位问题——它不会告诉你具体使用了哪个索引、扫描了多少文档。必须对慢查询语句附加 `explain("executionStats")` 进行彻底体检。 * **首要检查项**：`executionStats.executionStages.stage`。如果显示为 `"COLLSCAN"`，说明完全没有走索引，这是最根本的问题。 * **对比关键指标**：`executionStats.nReturned` 与 `executionStats.totalDocsExamined`。如果后者远大于前者（比如扫描了10万条文档才返回10条），大概率是索引未覆盖查询字段或字段顺序不合理。 * **确认索引命中**：检查 `executionStats.executionStages.inputStage.keyPattern`，确保实际命中的索引正是你期望的那一个。例如，避免让 `company_id_hashed` 哈希索引顶替组合索引，因为哈希索引对范围查询完全无效。 * **6.0及以后版本**：`explain("allPlansExecution")` 会真实执行所有候选计划，可能引发锁表或增大负载，线上环境请谨慎使用。 ### 第三步：借助 `$indexStats` 清理冗余“僵尸索引” 索引建了一堆却不定期清理，写入性能会越来越差。在6.0和7.0中，通过聚合阶段 `$indexStats` 可以直观地查看索引的真实使用频率。 * **执行命令**：`db.collection.aggregate([ { $indexStats: {} }, { $sort: { "accesses.ops": 1 } } ])`，按访问次数升序排列，排在末尾的就是几乎未被使用的“僵尸索引”。 * **字段含义**：`accesses.ops` 自MongoDB 3.2起开始统计命中次数。如果某个索引的 `accesses.ops` 为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`，才算真正优化成功。 真正卡住人的地方往往不是命令怎么敲，而是开启了profile却没有去查询 `system.profile`，或者是看了 `explain` 却忽略了 `totalDocsExamined` 和 `keyPattern` 的对应关系。索引不是建得越多越好，而是要让每一条慢查询，都能精准地落在一个“最小必要”的索引上。