复合索引更有效，因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，严重拖慢响应。
本文档主要讲述的是用Apache Spark进行大数据处理——第一部分：入门介绍；Apache Spark是一个围绕速度、易用性和复杂分析构建的大数据处理框架。最初在2009年由加州大学伯克利分校的AMPLab开发，并于2010年成为Apache的开源项目之一。 在这个Apache Spark文章系列的第一部分中，我们将了解到什么是Spark，它与典型的MapReduce解决方案的比较以及它如何为大数据处理提供了一套完整的工具。希望本文档会给有需要的朋友带来帮助；感
如何验证索引是否真正生效
别只看有没有建索引，要看它是否被实际使用、效果如何。关键靠 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 可能继续沿用过时的执行路径。
