先说一个核心结论：索引设计与查询性能，本质上是一场数据检索路径的博弈。在 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 可能会继续沿用旧的执行路径，使新索引的优势无法立即体现。
