一起聊聊mongodb索引那些事儿，怎么用才不迷糊，性能提升其实没那么难

今天咱们就敞开聊一聊MongoDB里的索引,很多人一听到“索引”俩字，脑子里可能立刻浮现出厚厚的教科书和一堆看不懂的符号，觉得这玩意儿特别高深，是资深工程师才能玩转的东西，其实不然，索引说白了，就像一本厚书最前面的目录，你想啊，没有目录的书，你要找某个章节的具体内容，是不是得从第一页开始一页一页地翻？那得多慢啊，数据库也是一样，没有索引，它要找你想要的数据，就得把整个表（在MongoDB里叫集合）从头到尾扫描一遍，这叫“全表扫描”，效率非常低。

索引的核心目的就一个：加快查询速度，它通过给数据预先建立一个有规律的“目录”，让数据库能够像我们查字典一样，快速定位到数据所在的位置，避免傻乎乎地全表扫描。

那MongoDB里都有哪些常见的“目录”呢？

最常见的,也是你几乎一定会用到的，就是单字段索引，比如你有一个用户集合，里面每个文档都有userId、name、createTime这些字段，如果你经常根据userId来查用户信息，那么给userId字段建立一个单字段索引就是最明智的选择，这就好比给电话本按姓氏笔画做了个目录，找姓“张”的就不用从“阿”开始翻了。

比单字段索引再厉害一点的,是复合索引，这个名字听着唬人，其实很简单，就是同时给多个字段一起建一个索引，比如你不仅经常用userId查，还经常组合查询，查找某个城市里，年龄大于30岁的用户”，这时候，如果你给city和age这两个字段建立一个复合索引，查询起来就会快很多。

这里有个非常重要的知识点,也是很多人容易迷糊的地方：复合索引字段的顺序非常关键！ 这就像一本先按省份、再按城市排序的通讯录，你想找“广东省深圳市”的朋友，这个目录非常管用，但如果你想直接找所有叫“深圳市”的（不管在哪个省），这个目录的帮助就小了很多，因为你可能还是得把每个省下面的深圳市都看一遍，建立复合索引时，要把最常用、筛选性最强的字段放在前面，这个原则被称为“ ESR规则”（Equality, Sort, Range），但咱们不记术语，你就记住：先放等值查询的字段（比如city=“深圳”），再放排序的字段（比如按age倒序），最后放范围查询的字段（比如age > 30），这个顺序用对了，索引效果事半功倍。

除了这两种,MongoDB还有其他类型的索引，比如多键索引，它专门用于数组字段，比如你的文档里有一个tags标签数组，给这个字段建多键索引后，查询包含某个标签的文档就会很快，还有文本索引，用来做全文搜索，比如在文章内容里搜索关键词，以及地理空间索引，用来处理地理位置查询，查找我附近1公里内的餐厅”。

光有索引就行了吗？当然不是，用不对反而更糟。

索引最大的代价就是“占地方”和“拖慢写操作”，你每新建一个索引，就像给书多做了一个目录，这本书自然就更厚了，占用的磁盘空间就大了，更重要的是，当你往书里添加新内容（插入数据），或者修改、删除内容时，你不仅要把书页本身改好，还得去更新所有的目录，保证目录和内容是对得上的，索引不是越多越好，你建一堆用不上的索引，只会白白浪费存储空间，并且严重拖慢你的写入（增、删、改）速度，这就叫“索引是双刃剑”。

那怎么知道我的索引用没用好呢？

MongoDB提供了一个非常实用的工具,叫explain()，你可以在你的查询语句后面加上.explain()，它就会告诉你这次查询是怎么执行的，它会详细说明：有没有用到索引？用了哪个索引？扫描了多少文档？通过这些信息，你就能判断你的索引是否有效，如果发现查询进行了“COLLSCAN”（集合扫描，也就是全表扫描），或者扫描的文档数量远大于返回的数量，那就说明你的索引可能没建对，或者根本没用上索引，这时候你就需要考虑优化索引了。

咱们总结几个不迷糊的要点：

1. 索引像目录，核心是提速查询。
2. 常用的索引是单字段和复合索引，复合索引的顺序是门道。
3. 索引不是免费的，它会占用空间、影响写入，别乱建。
4. 善用explain()工具，它是你检查索引效果的“照妖镜”。

性能提升没那么难,关键是从小处着手，先给你最核心、最常用的查询条件加上合适的索引，往往就能解决80%的性能问题，别想着一口吃成胖子，一步步来，你的MongoDB应用就会越来越快。