MongoDB大数据量查询慢怎么办_通过创建复合索引遵循ESR原则优化

复合索引更有效，因MySQL/MongoDB一次查询通常只用一个索引，多个单列索引无法协同；复合索引按ESR（等值→排序→范围）顺序组织，支持多条件精准过滤与排序，避免回表、内存扫描及全表扫描。

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

多个单字段索引无法协同加速多条件查询。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 不一定自动选最优索引，尤其当集合上存在多个相似复合索引时。它可能选错，或退化为 COLLSCAN。

• 强制指定索引：用 .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 可能继续沿用过时的执行路径。