MongoDB索引优化建议：从慢查询到毫秒级响应的实战指南
用MongoDB的人都知道索引重要，但真要优化起来经常摸不着头脑。查询慢了就加索引，结果索引越加越多，写入反而变慢了，内存占用也上去了。到底该建哪些索引，怎么设计复合索引的字段顺序，索引多了会不会有副作用？这些问题困扰着不少开发者。本文从实战角度出发，讲清楚MongoDB索引优化的核心思路和常见坑点，让你的查询性能真正提上来。
先用explain分析查询瓶颈
优化索引之前，先要确认问题在哪。用explain()方法分析慢查询，看executionStats里的关键指标：totalDocsExamined（扫描的文档数）、totalKeysExamined（扫描的索引键数）、executionTimeMillis（执行时间）。如果totalDocsExamined远大于返回的文档数，说明做了大量无效扫描，需要优化索引。如果stage是COLLSCAN（全表扫描），说明没有用到索引。理想情况是totalKeysExamined接近返回文档数，stage是IXSCAN（索引扫描）或FETCH（基于索引取文档）。explain还能看到索引选择情况，如果MongoDB选错了索引，可以用hint()强制指定。先诊断清楚再动手，别盲目加索引。
单字段索引：最基础但要选对字段
单字段索引是最简单的索引类型，对单个字段建立B树。选择建索引的字段要看查询模式和选择性。查询频率高的字段（如用户ID、订单状态、时间戳）应该建索引。选择性高的字段（值分布均匀、重复度低）索引效果好，比如唯一ID、邮箱；选择性低的字段（如性别、布尔值）索引效果差，可能还不如全表扫描。用db.collection.distinct('field').length查看字段的distinct值数量，和总文档数对比，如果占比低于10%，索引效果有限。另外，排序字段也要建索引，否则MongoDB会在内存里排序，超过32MB就报错。
复合索引：字段顺序决定效果
复合索引支持多个字段的组合查询，但字段顺序非常关键。遵循ESR原则：Equality（等值查询字段）放最前，Sort（排序字段）放中间，Range（范围查询字段）放最后。比如查询{status: 'active', created_at: {$gte: date}}并按created_at排序，索引应该是{status: 1, created_at: 1}，而不是反过来。因为MongoDB的复合索引是按字段顺序建B树，必须从左往右匹配。索引{a, b, c}可以支持查询{a}、{a, b}、{a, b, c}，但不支持{b}或{c}。设计复合索引时，分析最常见的查询组合，把重叠的字段提前，用一个索引覆盖多种查询，避免建太多索引。
覆盖索引：不回表查询最快
覆盖索引是指查询的所有字段都在索引中，MongoDB不需要回表取完整文档，直接从索引返回结果，性能极高。比如查询db.users.find({age: 25}, {age: 1, name: 1, _id: 0})，如果有索引{age: 1, name: 1}，就能完全从索引返回数据。注意要在projection里排除_id字段（除非_id也在索引中），否则还是要回表。覆盖索引适合查询字段少且固定的场景，如API接口返回特定字段、聚合统计。但不要为了覆盖索引把所有字段都加进去，索引太大反而影响性能。权衡查询频率和索引大小，只为高频查询设计覆盖索引。
部分索引和稀疏索引：节省空间提高效率
部分索引（Partial Index）只为满足条件的文档建索引，大幅减少索引大小。比如只为status为active的订单建索引：db.orders.createIndex({user_id: 1}, {partialFilterExpression: {status: 'active'}})。查询active订单时走索引，查询其他状态时全表扫描。适合大量文档中只有一小部分需要频繁查询的场景，如活跃用户、未完成订单。稀疏索引（Sparse Index）只为存在该字段的文档建索引，适合可选字段。比如email字段不是所有用户都有，建稀疏索引db.users.createIndex({email: 1}, {sparse: true})。部分索引和稀疏索引能让索引更精准，减少内存占用和维护成本。
避免索引陷阱：不是越多越好
索引不是免费的，每个索引都要占内存和磁盘，写入时要同步更新所有索引，影响写入性能。索引太多会让MongoDB在查询时纠结选哪个，甚至选错。建议每个集合的索引数量控制在5个以内，最多不超过10个。定期用db.collection.stats()检查索引大小，如果索引总大小接近可用内存，部分索引会被换出到磁盘，性能骤降。删除不用的索引：用MongoDB的慢查询日志或监控工具找出从未用过的索引（executionStats.indexesUsed），果断删掉。还要避免冗余索引，比如已经有{a, b}的复合索引，就不需要单独的{a}索引了（复合索引的前缀可以单独使用）。
索引维护：定期分析和重建
索引用久了会产生碎片，尤其是频繁更新的集合。用db.collection.reIndex()重建索引，整理碎片回收空间，但会阻塞写入操作，生产环境要在业务低峰期做。MongoDB 4.4之后建议用db.collection.createIndex()加background: true参数在线重建。还要定期检查索引使用情况，用db.collection.aggregate([{$indexStats: {}}])看每个索引的访问次数，把访问量极低的索引删掉。对于分片集合，索引策略更复杂，分片键本身会有索引，查询时要尽量带上分片键，否则会跨分片扫描。云MongoDB通常有自动分析和优化建议，定期看看控制台的慢查询分析和索引建议，能发现不少优化点。
常见问题
查询用了索引但还是很慢，怎么办？
用explain看totalKeysExamined，如果扫描的索引键太多，说明索引选择性不够或查询条件太宽泛。优化方法是缩小查询范围、增加过滤条件、或用复合索引提高选择性。还要检查排序和聚合操作是否在内存里做，考虑针对性建索引。
什么情况下索引会失效？
几种常见情况：查询条件用了$ne、$nin、$or（需要特殊处理）、正则表达式不是前缀匹配、类型不匹配（字段是字符串但查数字）、查询条件用了函数或运算。尽量用等值查询和范围查询，避免复杂条件。
开发环境和生产环境索引策略要一样吗？
最好一样，否则开发环境测不出性能问题。但生产环境数据量大，索引效果更明显，可能需要额外的索引。建议定期把生产环境的慢查询拿到开发环境重现，用真实数据量测试索引效果。
总结
MongoDB索引优化的核心是理解查询模式，针对高频查询设计精准的索引。单字段索引看选择性，复合索引看字段顺序，覆盖索引看投影字段，部分索引看数据分布。不要盲目加索引，每个索引都有维护成本，要在查询性能和写入性能之间找平衡。用explain诊断问题，用监控工具跟踪索引使用情况，定期清理无效索引。索引设计没有银弹，要根据实际业务场景不断调整优化。掌握这些原则和技巧，你的MongoDB查询性能就能从秒级降到毫秒级，真正发挥出文档数据库的优势。