诊断和解决 MongoDB 慢查询：实用指南

MongoDB 慢查询通常出现在数据增长、访问模式改变或索引不再匹配应用程序读取数据的方式时。你可能会注意到 API 端点超时、仪表板加载缓慢，或者即使流量看起来正常，CPU 和磁盘 I/O 也在上升。

使用分析器找到慢操作，explain() 查看 MongoDB 如何运行它，以及有针对性的索引来减少 MongoDB 必须做的工作。

了解查询变慢的原因

在更改索引之前，先检查常见原因：

1. 缺失或无效的索引： 没有有用的索引，MongoDB 可能会执行集合扫描并检查每个文档。
2. 查询复杂性： 需要聚合阶段、大型排序或跨集合查找的操作，如果未优化，本质上可能会很慢。
3. 数据量： 即使是有索引的查询，如果数据集庞大且查询在过滤前仍需处理数百万个文档，也可能会变慢。
4. 硬件限制： 内存不足（导致大量磁盘交换）或磁盘 I/O 缓慢会降低所有操作的性能。

第一步：使用分析器识别慢查询

解决的第一步是识别。MongoDB 的数据库分析器记录数据库操作的执行时间，使你能够精确定位哪些查询导致了问题。

启用和配置分析器

分析器在不同级别运行。级别 0 禁用分析。级别 1 记录慢于配置阈值的操作。级别 2 记录所有操作。

为了分析慢查询，通常设置级别 1，阈值为 50 毫秒：

// 切换到要分析的数据库
use myDatabase

// 捕获耗时超过 50 毫秒的操作
db.setProfilingLevel(1, { slowms: 50 })

查看分析器结果

记录的慢操作存储在 system.profile 集合中。你可以查询此集合以查看最近的慢查询：

// 查找耗时超过 50ms 的操作
db.system.profile.find({ ns: "myDatabase.myCollection", millis: { $gt: 50 } }).sort({ ts: -1 }).limit(10).pretty()

仅在短期调查中保持级别 2。它会记录每个操作，并可能在繁忙的生产数据库上增加开销。

第二步：使用 explain() 分析查询执行

一旦识别出慢查询，使用 explain() 查看 MongoDB 如何处理它。

使用 explain('executionStats')

executionStats 详细级别提供了最全面的输出，包括实际执行时间和资源利用率。

考虑这个针对 users 集合的慢查询：

db.users.find({ status: "active", city: "New York" }).sort({ registrationDate: -1 }).explain('executionStats')

解释输出

explain() 输出中需要检查的关键字段有：

字段	描述	慢查询的指标
winningPlan stages	优化器选择的执行计划。	查找 COLLSCAN、阻塞 SORT 或意外的索引。
executionStats.nReturned	操作返回的文档数。	当预期结果很少时，数字高通常表明早期过滤不佳。
executionStats.totalKeysExamined	检查了多少索引键。	如果有效使用索引，通常应接近 nReturned。
executionStats.totalDocsExamined	实际从磁盘/内存中检索了多少文档。	数字高表明索引选择性不够。
executionStats.executionTimeMillis	执行所用的总时间。	将其与实际延迟进行比较。

红色警报：COLLSCAN

如果获胜计划包含 COLLSCAN，则 MongoDB 扫描了集合。这通常意味着查询需要更好的索引，谓词不具有选择性，或者查询形状阻止使用索引。

第三步：实施索引策略

解决 COLLSCAN 通常涉及创建或调整索引以匹配查询模式。

创建复合索引

对于涉及多个字段的查询，例如等值匹配、范围过滤或排序，通常需要复合索引。常见的 ESR 指南按等值谓词、排序字段、范围谓词的顺序排列复合索引字段。这是一个指南，不能替代使用真实查询和数据进行测试。

示例场景： 查询：db.orders.find({ status: "PENDING", customerId: 123 }).sort({ orderDate: -1 })

基于 ESR，索引应遵循以下结构：

1. 等值谓词（status、customerId）
2. 排序谓词（orderDate）

创建索引：

db.orders.createIndex( { status: 1, customerId: 1, orderDate: -1 } )

此索引允许 MongoDB 快速按状态和客户 ID 过滤，然后高效地检索已按 orderDate 排序的结果。

处理排序操作

如果 explain() 显示在检查了许多文档后出现了阻塞的 SORT 阶段，则 MongoDB 无法使用索引以排序顺序返回结果。

大型排序会消耗内存，并可能根据服务器版本和命令选项溢出到磁盘。更好的修复方法通常是创建一个同时支持过滤和排序的索引。

确保 .sort() 子句中使用的字段作为适当的复合索引中的尾随元素存在。

第四步：高级优化技术

如果仅靠索引无法解决缓慢问题，请考虑以下高级步骤：

投影优化

使用投影（.find() 的第二个参数）仅返回应用程序需要的字段。这减少了网络传输，并且当投影字段在索引中时，可以实现覆盖查询。

// 仅返回 _id、name 和 email 字段
db.users.find({ city: "Boston" }, { name: 1, email: 1, _id: 1 })

覆盖索引

覆盖索引是最终的性能目标。当查询所需的所有字段（在过滤、投影和排序中）都存在于索引本身时，就会发生这种情况。发生这种情况时，MongoDB 永远不需要获取实际文档（避免了 COLLSCAN，并且 totalDocsExamined 将为 0 或非常低）。

在 explain() 输出中，覆盖索引会导致阶段显示 IXSCAN 并且 totalDocsExamined 为 0。

硬件和配置审查

如果 totalKeysExamined 和 totalDocsExamined 看起来合理但延迟仍然很高，请查看查询形状之外的因素。检查工作集是否适合内存，磁盘延迟是否高，以及服务器是否处于写入压力、锁争用或 CPU 饱和状态。

要点

诊断 MongoDB 慢查询是一个循环：分析工作负载，解释慢查询，添加或调整索引，然后再次测量。一个好的修复方案会减少检查的文档数，消除可避免的集合扫描或阻塞排序，并改善用户实际感受到的请求路径。

可操作清单：

1. 临时启用分析器以捕获慢查询（slowms）。
2. 使用 explain('executionStats') 运行有问题的查询。
3. 检查 COLLSCAN 或高 totalDocsExamined。
4. 根据 ESR 规则创建或修改复合索引以覆盖过滤和排序。
5. 通过重新运行 explain() 命令验证改进。