MongoDB大数据量查询慢？用ESR原则创建复合索引优化

先说一个核心结论：索引设计和查询效率，本质上是一场数据检索路径的博弈。在MongoDB和MySQL这类数据库中，复合索引比多个单列索引能产生更高效的过滤效果，这一点已在实践中反复验证。

为什么复合索引比多个单字段索引更有效

在大多数情况下，MongoDB一次查询只能利用一个索引（索引交集功能受限于特定场景，且不一定生效）。这意味着为多个字段分别建立单字段索引，几乎无法协同工作。举个直观的例子：db.payments.find({ currency: "USD", status: "paid", amount: { $gte: 100 } })。即便你分别为currency、status、amount建立了索引，MongoDB很可能只选择其中一个字段的索引来缩小扫描范围，其余条件仍需在内存中过滤。结果就是totalDocsExamined居高不下，性能不升反降。 复合索引的做法则不同。它将多个字段按指定顺序组织进一棵B-tree，使MongoDB能够一次性定位到满足所有等值条件的文档区间，再在这一区间内高效完成范围扫描和排序操作。 - 单字段索引适合独立、低频的简单查询场景 - 复合索引则更适用于高频、固定模式的业务查询，例如“查询USD已支付的订单，金额≥100，按时间倒序” - 另外需要注意，索引数量越多，写入时的开销就越大。WiredTiger引擎中dhandle的内存占用也会随之增加，当库表数量较多时，这一问题甚至可能放大为锁等待

ESR原则：等值→排序→范围，顺序不能错

ESR原则正是构建高效复合索引的核心口诀。它规定了字段在索引中的排列顺序：等值字段放在前，排序字段放在中间，范围字段放在最后。顺序一旦调整，索引效果就会大打折扣。 - 等值（Equality）：例如{ currency: "USD", status: "paid" }，这些字段的查询条件是精确匹配，应放在索引的最前面 - 排序（Sort）：如.sort({ paidAt: -1 })，排序字段的升序或降序必须与索引定义一致，放在等值后面 - 范围（Range）：如{ amount: { $gte: 100 } }，这类范围查询字段放在最后。当有多个范围字段时，优先将基数小（distinct值少）的放在前面，例如birthmonth（1-12）就比score（0-100）更适合放在前列 违反ESR，部分字段就无法走索引。例如错误地把amount放在paidAt前面：索引定义为{ currency: 1, amount: 1, paidAt: -1 }，但查询中需要.sort({ paidAt: -1 })。此时排序字段的索引顺序就乱了，MongoDB必须额外做in-memory sort，响应速度自然快不起来。

如何验证索引是否真正生效

验证索引是否被实际使用，最好的方法不是靠直觉，而是靠数据。关键工具是explain("executionStats")。以下是几个需要重点关注的检查点： - 检查queryPlanner.winningPlan.stage：必须是IXSCAN而不是COLLSCAN - 对比executionStats.totalDocsExamined和nReturned：理想情况是两者接近，例如返回25条，扫描30条；而不是扫描50000条才返回25条 - 关注executionStats.totalKeysExamined：这个值越接近nReturned，说明索引过滤越精准 - 如果出现stage: "SORT"且memUsage很大，说明排序没有走索引，ESR顺序大概率错了 执行示例：

db.payments.find({ currency: "USD", status: "paid", amount: { $gte: 100 } }).sort({ paidAt: -1 }).explain("executionStats")

容易被忽略的细节：索引选择、覆盖查询与分页陷阱

MongoDB并不总是自动帮你选择最优的索引。特别是在集合上存在多个相似的复合索引时，它有可能选错，甚至退化为全表扫描。 - 强制指定索引：使用.hint({ currency: 1, status: 1, paidAt: -1, amount: 1 })，直接告诉MongoDB用哪个索引 - 覆盖查询（Covered Query）：如果查询投影只包含索引字段（例如.project({ currency: 1, status: 1, paidAt: 1, _id: 0 })），MongoDB可以直接从索引中返回数据，不需要读取文档，这是进一步的加速手段 - 分页慎用skip：即使有索引，.skip(10000).limit(20)仍然需要跳过1万条索引项，耗时线性增长。推荐使用“游标分页”的方式，记住上一页最后一条的paidAt和_id，写下一页查询条件：{ paidAt: { $lt: lastPaidAt }, _id: { $lt: lastId } } 还有一个容易忽略的步骤：建完索引后，最好清理旧的查询计划缓存。执行db.runCommand({ clearQueryCache: "payments" })，否则MongoDB可能会继续使用过时的执行路径，新索引的优势无法立即体现出来。