1. 为什么索引操作值得单独拎出来讲
但凡用过一段时间数据库的人，大概都听过一句话：索引是查询性能的生命线。这话不夸张。我在实际项目里见过太多这样的情况——同一张表，同一条查询语句，加索引前后响应时间从几百毫秒直接掉到几毫秒，也见过因为索引建错了方向，写入性能直接腰斩。MongoDB 作为文档型数据库，它的索引机制和传统关系型数据库有相似的地方，但也有很多自己的脾气。很多人从 MySQL 转过来，觉得建索引不就是CREATE INDEX换个写法嘛，结果踩了一堆坑。
这篇内容就是围绕 MongoDB 的索引操作展开的，从最基础的创建、查看、删除，到复合索引的字段顺序问题、唯一索引与稀疏索引的适用场景、TTL 索引的自动过期机制，再到用explain()分析索引命中情况。适合已经能跑通 MongoDB 基本增删改查、想进一步把查询性能调优这件事搞明白的开发者。如果你还没装过 MongoDB，建议先把环境搭起来，后面所有操作我都尽量给出可直接复制运行的命令。
索引这个东西，本质上就是用空间换时间。数据库在磁盘上多维护一份排好序的数据结构，查询的时候就不用全表扫描，直接定位到目标文档。MongoDB 的索引底层是 B-Tree 结构（准确说是 B-Tree 的变体），每个索引条目指向对应的文档位置。理解这一点，后面很多操作的设计意图就顺了。
2. 索引操作的核心思路与方案选型
2.1 先搞清楚 MongoDB 默认给你建了什么索引
很多人不知道，MongoDB 在创建集合的时候，会自动在_id字段上建一个唯一索引。这个索引你删不掉，也不用管它。它的存在意味着：任何基于_id的查询都是走索引的，性能有保障。但除了这个之外，MongoDB 不会自动帮你建任何其他索引。这一点和某些数据库的自动索引推荐机制不一样，MongoDB 把决定权完全交给你。
所以实际开发中，索引策略必须由开发者根据查询模式来设计。我的习惯是：先把业务里高频的查询语句列出来，看它们的过滤条件、排序字段、返回字段分别是什么，然后针对性地设计索引。不要凭感觉建，也不要一次性建一大堆“备用”索引，因为每个索引都会增加写入时的开销。
2.2 单字段索引、复合索引、多键索引怎么选
MongoDB 支持的索引类型挺多，日常用得最多的三类是：
- 单字段索引：只对一个字段建索引，适合该字段经常作为查询条件的场景。
- 复合索引：对多个字段联合建索引，字段顺序很关键，后面会详细讲。
- 多键索引：当字段值是数组时，MongoDB 会为数组中的每个元素建索引条目，这个通常是自动的，你不需要特殊声明。
选哪种，取决于你的查询模式。如果查询条件经常是多个字段组合，那复合索引通常比建多个单字段索引更高效。因为 MongoDB 在一次查询中一般只会用一个索引（除非用到索引交集，但那个效率不一定高），复合索引能一次性覆盖多个条件。
2.3 索引方向：1 和 -1 到底有什么区别
创建索引的时候要指定方向，1表示升序，-1表示降序。对于单字段索引来说，方向其实无所谓，因为 MongoDB 可以正向或反向遍历索引。但对于复合索引，方向就重要了——它决定了索引中字段的排序方式，进而影响排序操作能否走索引。
举个例子，如果你经常执行db.orders.find().sort({createTime: -1, amount: 1})，那建索引时就应该用{createTime: -1, amount: 1}，这样排序才能直接利用索引的顺序。如果方向反了，MongoDB 可能就需要在内存中重新排序，数据量大时性能会明显下降。
3. 索引的创建、查看与删除实操
3.1 创建索引的几种写法与参数说明
最基本的创建索引命令是db.collection.createIndex()。我拿一个订单集合来举例，假设集合名叫orders，文档结构大概长这样：
{ _id: ObjectId("..."), orderNo: "ORD20240101001", userId: "U10086", status: "paid", amount: 299.00, createTime: ISODate("2024-01-01T10:00:00Z"), tags: ["electronics", "urgent"] }给userId建一个单字段升序索引：
db.orders.createIndex({ userId: 1 })给status和createTime建一个复合索引，status 升序、createTime 降序：
db.orders.createIndex({ status: 1, createTime: -1 })创建索引时可以带一些选项，常用的有：
db.orders.createIndex( { orderNo: 1 }, { unique: true, // 唯一索引 name: "idx_orderNo", // 自定义索引名 sparse: true, // 稀疏索引 expireAfterSeconds: 3600 // TTL 索引，单位秒 } )注意：
unique、sparse、expireAfterSeconds这几个选项不能随便混用。比如 TTL 索引必须是单字段索引，且字段类型必须是日期类型或者包含日期类型的数组。
3.2 查看现有索引：getIndexes 与 $indexStats
查看一个集合上所有索引：
db.orders.getIndexes()返回结果会列出每个索引的键、名称、唯一性等信息。索引名如果不指定，MongoDB 会自动生成，规则是“字段名_方向”，比如userId_1、status_1_createTime_-1。
想看索引的实际使用情况，可以用聚合管道里的$indexStats：
db.orders.aggregate([{ $indexStats: {} }])这个命令会返回每个索引被访问的次数（accesses.ops）和最近一次使用时间。我经常用它来排查“哪些索引建了但从来没被用过”，这些索引就是可以考虑删掉的候选。
3.3 删除索引：按名称删与按键模式删
删除单个索引，用索引名：
db.orders.dropIndex("idx_orderNo")也可以按键模式删：
db.orders.dropIndex({ orderNo: 1 })删除除_id之外的所有索引：
db.orders.dropIndexes()实操心得：删除索引在生产环境要谨慎。我一般会先在从节点或者测试环境验证，确认删除后没有慢查询恶化，再推到主库。另外，删除索引本身是一个相对轻量的操作，但重建索引在大集合上可能很耗时，所以删之前想清楚。
3.4 后台建索引与前台建索引的区别
早期 MongoDB 版本里，建索引分前台和后台。前台建索引会阻塞所有写操作，后台建索引不阻塞写但速度慢。从 4.2 版本开始，MongoDB 对建索引的过程做了优化，基本不再需要手动指定后台了。但在大集合上建索引仍然可能对性能有影响，建议在业务低峰期操作。
如果你用的是较老版本，可以这样指定后台建索引：
db.orders.createIndex({ userId: 1 }, { background: true })4. 复合索引的字段顺序与查询匹配规则
4.1 最左前缀原则在 MongoDB 里同样适用
复合索引{ a: 1, b: 1, c: 1 }可以支持的查询模式包括：
- 只查
a - 查
a和b - 查
a、b和c - 查
a和c（这种情况下a能用索引，c不能直接利用索引顺序，但可能做索引过滤）
不能高效支持的是：只查b、只查c、查b和c。这就是最左前缀原则。所以设计复合索引时，要把最常用于过滤的字段放在最左边。
4.2 排序与范围查询对索引顺序的影响
这里有一个容易踩的坑：如果复合索引中某个字段用于范围查询（比如$gt、$lt），那么它后面的字段在排序时可能无法利用索引。
举个例子，索引是{ status: 1, createTime: -1 }，查询是：
db.orders.find({ status: "paid", createTime: { $gt: ISODate("2024-01-01") } }).sort({ createTime: -1 })这个查询里，status是等值匹配，createTime是范围条件，排序也是createTime。这种情况下，索引可以支持排序，因为范围字段正好是排序字段。但如果排序字段是范围字段后面的另一个字段，就可能需要内存排序了。
4.3 覆盖查询：让查询完全走索引
如果一个查询的所有返回字段都包含在索引里，MongoDB 就可以直接从索引返回结果，不需要回表读取文档。这叫覆盖查询（covered query），效率非常高。
比如索引{ status: 1, amount: 1 }，查询：
db.orders.find({ status: "paid" }, { _id: 0, status: 1, amount: 1 })注意这里必须显式排除_id，否则_id不在索引里，就无法覆盖。用explain()可以看到totalDocsExamined为 0，说明没有扫描文档。
5. 特殊索引类型的使用场景与避坑
5.1 唯一索引：保证字段值不重复
唯一索引用来约束字段值的唯一性。比如订单号：
db.orders.createIndex({ orderNo: 1 }, { unique: true })如果插入重复的 orderNo，MongoDB 会报错。但要注意：如果字段在部分文档中不存在，唯一索引默认会把“缺失”也当作一个值，所以多个文档都缺失该字段时会冲突。这时候可以用稀疏唯一索引：
db.orders.createIndex({ orderNo: 1 }, { unique: true, sparse: true })这样只对存在该字段的文档做唯一性约束。
5.2 稀疏索引与部分索引的区别
稀疏索引只索引包含该字段的文档。部分索引（partial index）则更灵活，可以指定一个过滤条件，只对满足条件的文档建索引：
db.orders.createIndex( { userId: 1 }, { partialFilterExpression: { status: "paid" } } )部分索引比稀疏索引更推荐，因为它能精确控制索引覆盖的文档范围，减少索引体积，同时也能被查询优化器更好地利用。
5.3 TTL 索引：自动清理过期数据
TTL 索引可以自动删除过期文档，适合日志、会话、验证码这类有时效性的数据：
db.sessions.createIndex({ expireAt: 1 }, { expireAfterSeconds: 0 })这里expireAfterSeconds: 0表示文档在expireAt时间点之后被删除。MongoDB 后台有个线程每 60 秒跑一次，扫描并删除过期文档，所以删除不是精确到秒的，会有最多 60 秒的延迟。
注意：TTL 索引字段必须是日期类型（Date）或者包含日期的数组。如果字段是字符串类型的时间，TTL 不会生效。
5.4 文本索引与地理索引的简单提及
文本索引用于全文搜索：
db.articles.createIndex({ title: "text", content: "text" })地理索引用于位置查询，分 2dsphere 和 2d 两种。这两类索引比较专用，这里不展开，但要知道它们的存在，遇到对应场景时知道往哪个方向查。
6. 用 explain 分析索引命中与性能排查
6.1 explain 的三种模式
explain()支持三种 verbosity 模式：
queryPlanner：默认模式，显示查询计划的选择过程。executionStats：显示执行统计信息，最常用。allPlansExecution：显示所有候选计划的执行情况。
用法：
db.orders.find({ status: "paid" }).explain("executionStats")6.2 关键指标解读
在executionStats模式下，重点看这几个字段：
| 指标 | 含义 | 理想值 |
|---|---|---|
stage | 查询阶段 | IXSCAN表示走索引，COLLSCAN表示全表扫描 |
totalKeysExamined | 扫描的索引键数 | 越接近返回文档数越好 |
totalDocsExamined | 扫描的文档数 | 越接近返回文档数越好 |
executionTimeMillis | 执行耗时 | 越低越好 |
nReturned | 返回文档数 | 业务预期值 |
如果看到COLLSCAN，说明没走索引，需要检查查询条件是否匹配现有索引。如果totalDocsExamined远大于nReturned，说明索引选择性不好，可能需要调整索引或查询条件。
6.3 常见慢查询的索引排查思路
我一般的排查顺序是：
- 用
explain("executionStats")看是否走索引。 - 如果走了索引但慢，看
totalKeysExamined和totalDocsExamined是否过大。 - 检查复合索引字段顺序是否合理。
- 检查是否有排序操作导致内存排序（
stage出现SORT）。 - 考虑是否需要调整索引或重写查询。
实操心得：
explain的结果里如果出现SORT_KEY_GENERATOR或SORT阶段，说明排序没走索引。这时候要么调整索引方向，要么接受内存排序的成本。大集合上的内存排序可能触发 32MB 限制，直接报错。
7. 索引维护与线上操作的注意事项
7.1 索引不是越多越好
每个索引都会占用磁盘空间，并且在插入、更新、删除时都需要维护。我见过一个集合上建了十几个索引，写入性能惨不忍睹。定期用$indexStats检查索引使用率，把accesses.ops为 0 或极低的索引清理掉。
7.2 大集合建索引的注意事项
在几千万甚至上亿文档的集合上建索引，可能耗时几十分钟甚至更久。建议：
- 在业务低峰期操作。
- 先用小集合测试索引效果。
- 监控建索引过程中的内存和磁盘 IO。
- 如果是副本集，注意主节点建完索引后从节点也会跟进。
7.3 索引与写入性能的权衡
索引加速查询，但拖慢写入。这个权衡没有标准答案，取决于业务读写比例。读多写少的场景可以多建索引，写多读少的场景要克制。我的经验是：核心查询路径上的索引必须有，边缘查询可以接受全表扫描或者用其他方式优化。
7.4 索引重建与压缩
如果索引碎片化严重，可以考虑重建。MongoDB 提供了compact命令，但它会阻塞数据库级别的操作，生产环境慎用。更稳妥的方式是滚动重建：在从节点上逐个重建，再切换主从。
8. 常见问题速查与避坑清单
| 问题现象 | 可能原因 | 解决方向 |
|---|---|---|
| 查询慢，explain 显示 COLLSCAN | 没有匹配的索引 | 根据查询条件建索引 |
| 建了索引但没走 | 索引字段顺序不对或查询不匹配 | 检查最左前缀原则 |
| 唯一索引插入报重复 | 字段值重复或缺失 | 用稀疏唯一索引或检查数据 |
| TTL 索引不删除文档 | 字段类型不是日期 | 确认字段为 Date 类型 |
| 排序慢，explain 有 SORT | 排序字段未包含在索引中 | 调整索引方向或增加排序字段 |
| 索引占用空间过大 | 索引过多或字段值过长 | 清理无用索引，考虑部分索引 |
| 写入性能下降 | 索引维护开销大 | 减少索引数量，评估必要性 |
最后分享一个我踩过的坑：有一次给一个字段建了唯一索引，但那个字段在部分文档里是 null。结果插入第二条 null 值的文档时报了重复键错误。后来改成稀疏唯一索引才解决。所以建唯一索引前，一定要确认字段的缺失情况。
索引操作看起来简单，但真正用好需要结合具体业务场景反复调试。我的建议是：每次建索引前先想清楚要解决什么查询问题，建完后用 explain 验证效果，上线后定期用 $indexStats 回顾使用情况。这套流程跑顺了，MongoDB 的查询性能基本不会出大问题。
