MongoDB Compass 的 Performance 面板承担着慢查询诊断和索引效率评估的双重任务。打开某个集合后，切换到 Performance 标签页，可以看到当前时间段内执行过的操作列表，默认按执行时间从高到低排序。每一项记录包含操作类型、查询条件、排序规则、返回文档数、执行耗时以及扫描文档数。通过这些字段，开发者可以迅速判断某次查询是否因为缺少索引而扫描了过多数据。如果发现某条查询执行时间长，但返回的文档数很少，通常意味着索引设计不合理或者查询模式不适合当前数据结构。
Performance 面板的另一个价值在于它提供了 Explain Plan 视图。选中任意一条操作记录后，可以查看该查询对应的执行计划树，其中每个节点代表一个执行阶段，例如 IXSCAN（索引扫描）、FETCH（根据索引取出文档）、SORT（内存排序）或 COLLSCAN（全表扫描）。理解这些阶段的含义，是后续优化查询的基础。
一、核心指标与操作列表含义
在 Performance 面板中，每一条操作记录都对应一次真实的查询、插入、更新或删除。对于查询类操作，最值得关注的指标包括 Execution Time、Documents Returned、Documents Examined 和 Indexes Used。其中执行时间反映了单次操作的耗时，但它并不一定与查询复杂度直接相关，网络延迟、磁盘 I/O 和排序缓存都会影响最终结果。Documents Returned 表示满足条件的文档数量，而 Documents Examined 则是为找到这些文档而实际扫描的文档数量。如果两者差距悬殊，比如扫描了二十万条文档却只返回了三百条，基本可以判定查询没有有效利用索引。
除了这四项，操作列表还会显示查询条件和排序规则。把鼠标悬停在查询条件上，可以看到完整的过滤表达式。Compass 会智能地标出哪些字段在索引中，哪些字段没有命中索引。这个提示对设计复合索引很有帮助，因为复合索引的字段顺序必须与查询条件的组合方式匹配。例如查询条件同时包含 status 和 createdAt，而现有索引只建在 status 字段上，那么 createdAt 的过滤可能需要在内存中完成，导致额外的文档扫描。
另一个容易忽略的细节是排序操作。如果操作记录中显示 SORT 阶段，说明 MongoDB 无法直接利用索引顺序返回结果，需要把中间结果加载到内存中排序。当排序数据量超过 32MB 限制时，查询会直接报错，或者回退到磁盘排序，性能会显著下降。因此查看操作列表时，除了关注扫描文档数，还要留意是否出现了排序阶段。
二、从慢查询到执行计划：定位瓶颈
当操作列表中出现了耗时较长的查询，单击该记录即可打开对应的 Explain Plan 视图。Explain Plan 以树形结构描述查询的执行路径，最顶层是最终阶段，往下逐层展开。常见的阶段包括 COLLSCAN、IXSCAN、FETCH、SORT 和 LIMIT。其中 COLLSCAN 是最需要警惕的，它意味着 MongoDB 从头到尾遍历整个集合，复杂度与集合大小成正比。如果查询频繁触发 COLLSCAN，随着数据量增长，响应时间会逐步恶化。
下面这个查询尝试按订单状态和创建时间过滤，并按金额倒序排序：
db.orders.find({
status: "pending",
createdAt: { $gte: ISODate("2024-01-01") }
}).sort({ totalAmount: -1 }).explain("executionStats")
执行后可以在输出中看到 queryPlanner.winningPlan 字段。如果没有合适的索引，winningPlan 很可能是 COLLSCAN 加上 SORT。这样的执行计划表示数据库先扫描全部订单，再过滤出 pending 状态的文档，最后对结果做金额排序。即便集合只有几十万条记录，这种方案也会消耗大量 CPU 和内存。更好的方式是让查询通过复合索引直接定位到候选文档，并利用索引顺序完成排序。
如果已经在 Compass 中打开了这条操作记录，面板右侧会显示每个阶段的耗时估算和扫描文档数。从这里可以进一步确认瓶颈究竟发生在扫描阶段还是排序阶段。比如虽然 FETCH 阶段耗时不高，但 SORT 阶段占用了 400 毫秒，那么优化重点就是通过索引消除排序。
三、结合索引优化：减少文档扫描
理解了执行计划之后，下一步就是创建合适的索引。对于上面示例中的查询，复合索引的最佳字段顺序是 status、createdAt 和 totalAmount。因为查询首先对 status 做等值过滤，接着对 createdAt 做范围过滤，最后对 totalAmount 做降序排序。MongoDB 的复合索引遵循最左前缀规则，按照这个顺序建立索引，既可以满足前两个字段的过滤，也能利用第三个字段完成排序。
db.orders.createIndex({
status: 1,
createdAt: -1,
totalAmount: -1
})
创建索引后再次执行同样的查询，可以在 Explain Plan 中看到 winningPlan.inputStage 变成了 IXSCAN。查看 executionStats 时，totalDocsExamined 的值应该接近甚至等于 nReturned。这意味着数据库只扫描了必要的文档，没有再触碰无关数据。同时 totalKeysExamined 会和 totalDocsExamined 保持一个健康的关系，如果 totalKeysExamined 远大于 nReturned，说明索引选择性不够强，可能还需要调整查询条件或索引字段。
需要注意的是，复合索引虽然能显著提升查询性能，但也会增加写入成本和存储空间。每次插入、更新或删除文档时，MongoDB 都需要同步维护索引。因此不应该为每种查询都单独建一个索引，而是要分析真实业务中的高频查询模式，优先优化那些执行次数多、扫描文档多的操作。Compass 的 Performance 面板可以按执行次数排序，帮助开发者识别出最值得投入索引资源的场景。
四、常见性能问题与优化建议
除了全表扫描和内存排序，Performance 面板还能帮助发现其他几类问题。一是查询返回了过多字段，导致网络传输和文档解析开销增加。如果业务只需要订单号与金额，就不要使用 find() 不带投影地取出整个文档。可以在查询中加上投影参数，只返回必要字段。二是使用了低选择性的索引。比如在 status 字段上单独建索引，但如果 status 只有 pending、completed、canceled 三种取值，而 pending 占了全表 80% 的数据，这个索引的过滤效果就非常有限。此时应该结合其他高选择性字段一起建立复合索引。
另一个常见误区是忽略 limit() 与排序的配合。如果查询包含排序和限制返回数量，但没有合适的索引，MongoDB 仍然需要扫描并排序所有满足条件的文档，再截取前 N 条。这种模式在分页场景中尤其明显。优化思路是让索引同时覆盖过滤条件和排序字段，这样执行计划中会出现 LIMIT 阶段直接截断索引扫描，避免处理多余数据。
最后，定期观察 Performance 面板中的慢操作趋势，比一次性优化更有价值。随着数据分布变化，原本高效的索引可能逐渐失效。例如订单表持续增长，某个历史日期范围查询原本能命中少量文档，但随着时间推移，满足这一范围的数据越来越多，查询会重新变慢。建议在每次发布新功能或数据量出现明显增长后，回到 Compass 中查看新的慢查询记录，并重新评估索引策略。只有把性能分析融入日常开发流程，才能保持 MongoDB 查询的稳定响应。
MongoDB Compass性能分析索引优化修改时间：2026-08-28 08:52:03