MongoDB索引优化怎么做？6个常见问题一次说清
很多开发者用MongoDB时遇到查询慢的问题，第一反应是加索引，但索引加多了反而拖累写入性能，加少了查询还是慢。这篇用问答形式把索引优化的核心问题讲清楚。
问题1：什么情况下必须建索引？
当查询条件中的字段没有索引且集合数据量超过几万条时，MongoDB会全表扫描，查询耗时会随数据量线性增长。典型场景包括：
- 按用户ID查询用户信息
- 按订单号查询订单
- 按创建时间范围查询记录
MongoDB默认只给_id字段建了索引，其他字段需要手动创建。
问题2：复合索引怎么设计才高效？
复合索引的字段顺序非常关键，遵循最左匹配原则。举例：如果索引是 {status: 1, created_at: 1}，那么以下查询可以用到索引：
- 查询 status（可以）
- 查询 status + created_at（可以）
- 只查询 created_at（不能利用该索引）
高筛选度的字段放前面，比如精确匹配的字段优先于范围查询字段。
问题3：索引会不会拖累写入性能？
会。每增加一个索引，写入（insert/update/delete）时都需要同步更新索引结构，索引越多，写入越慢。建议：
- 读多写少的场景可以多建索引
- 写入频繁的集合只建必要的索引
- 避免在高频更新的字段上建索引
问题4：已有的索引怎么查看和分析？
使用 db.collection.getIndexes() 查看当前集合的所有索引，使用 explain('executionStats') 分析查询是否用到了索引以及扫描的文档数量。
- totalDocsExamined: 扫描的文档数，越少越好
- executionTimeMillis: 查询耗时
问题5：什么时候该用覆盖索引？
如果查询返回的字段全部包含在索引中，MongoDB可以直接从索引返回结果而不需要读取实际文档，这叫覆盖索引（Covered Query），性能最优。
适用场景：只查询少量字段，比如 {user_id: 1, status: 1} 的查询可以用覆盖索引 {user_id: 1, status: 1}。
问题6：云数据库MongoDB和自建有性能差异吗？
云数据库MongoDB底层用的是SSD存储，IO性能更稳定，同时有自动备份和监控告警能力，索引优化建议逻辑是一样的，但云版本运维成本更低。
常见问题
索引越多越好吗？
不是，索引会占用存储空间并拖累写入性能，只对高频查询的字段建索引，避免过度索引。
唯一索引和普通索引性能有差异吗？
查询性能基本一致，唯一索引主要用来保证数据唯一性约束，写入时会多一次检查开销。
已有数据的集合能后续补建索引吗？
可以，但大集合建索引会比较慢，建议在业务低峰期执行，或使用后台模式（background: true）。
总结
MongoDB索引优化的核心是找到高频查询字段、合理设计复合索引顺序、避免过度索引。对于生产环境的中大型应用，建议用云数据库MongoDB托管，能省下大量索引监控和性能调优的运维精力。