说一说mongodb组合索引的匹配规则

一、背景

有一张1000多万条记录的大表，需要做归档至历史表，出现了大量慢查询。
查询条件是

"classroomId": {$in: ["xxx", "xxx", ..... "xxx","xxx", "xxx" ] }

耗时近5秒，且是全表扫描

为什么没有使用到任何索引呢？

请看该集合创建的索引有哪些：

建立了两个组合索引userId_1_classroomId_1_isDelete_1和userId_1_classroomId_1,

但是二者的重复度极高。（可以删掉userId_1_classroomId_1_isDelete_1，再新建一个单索引classroomId_1）

二、组合索引

1、最左匹配原则

MongoDB 中组合索引遵循最左匹配原则，即在检索数据时从复合索引的最左边开始匹配。

举例来说，上文的组合索引userId_1_classroomId_1，对于查询条件 {“userId”: “xxx”, “classroomId”: “xxx”} 可以匹配该组合索引，因为查询条件包含了索引的最左前缀；而对于查询条件 {“classroomId”:“xxx”} 则无法匹配该组合索引。

但是对查询条件 {“userId”: “xxx”} 则可以匹配该组合索引。

所以，我们需要再新建一个单索引classroomId_1。

2、ESR规则

ESR（Equality, Sort, Range）规则是创建高效组合索引的一个重要原则

• Equality（相等）：将需要精确匹配的字段放在索引的前面。这些字段用于过滤数据，减少需要扫描的文档数量。例如查询 db.xxx.find({“classroomId”: “GM03DI890”}) 中，classroomId 字段是精确匹配，应放在索引的前面。
• Sort（排序）：排序操作应放在精确匹配字段之后。因为精确匹配可以减少需要排序的文档数量，且这样可以让 MongoDB 进行非阻塞排序。例如查询 db.xxx.find({“classroomId”: “GM03DI890”}).sort({createdOn: 1}) 中，createdOn 字段用于排序，应放在 classroomId 字段之后。
  也就是说，组合索引的顺序应该是classroomId_1_createdOn_1
• Range（范围）：范围查询字段应放在索引的最后面。范围查询会扫描一定范围内的数据，将其放在最后可以提高查询效率。例如查询 db.xxx.find({price: {$gte: 15000}}) 中，price 字段是范围查询，应放在索引的最后。

三、OR查询

如果是OR查询呢？

还是举如下例：

{"$or": [{"auth": 1},{"totalIds": {"$in": [1002482]}}]
}

应该分别对 auth 和 totalIds 字段创建单独的索引，而不是创建一个组合索引。

db.xxx.createIndex({"auth":1}, {"name":"auth_1","background":true})
db.xxx.createIndex({"totalIds":1}, {"name":"totalIds_1","background":true})

这是因为 MongoDB 在使用 or 查询时，如果每个子句都有自己的索引，那么 MongoDB 可以分别使用这些索引来执行查询，然后合并结果。这通常比创建一个包含所有字段的复合索引更有效。

1、区分度问题

区分度低的字段-- auth 字段的值只有两个（0 和 1），区分度很低。通常情况下，区分度低的字段单独建立索引的收益较小，因为索引的目的是快速定位数据，而区分度低的字段在索引中并不能有效减少需要扫描的数据量。

但我们还得考虑另外一个因素。

2、查询频率

如果 auth 字段在查询中非常频繁地被使用，即使区分度低，建立索引也可能带来一些性能提升。例如，如果大部分查询都包含 auth 字段，那么建立索引可以减少全表扫描的次数。

对于 or 查询，MongoDB 会分别使用每个子查询的索引，然后合并结果。

因此，为 auth 和 totalIds 分别建立单独的索引是合理的。这样可以确保每个子查询都能高效地使用索引。

四、执行计划

使用 explain 分析查询计划：

可以通过 explain 方法来分析查询计划，查看是否使用了索引以及索引的使用情况。

{"planSummary":"IXSCAN { totalIds: 1 }, IXSCAN { auth: 1 }"}

db.xxx.find({"$or":[{"auth":1},{"totalIds":{"$in":[636622]}}]}).explain("executionStats")

从执行计划可以看到，现在的OR查询能够使用到这两个单独索引。

五、总结

本文在OR查询中使用了分别创建两个单独索引来提高查询效率。

这里有一个问题，auth字段的区分度低，而totalIds字段的区分度高。

在索引及文档扫描的时候，整个查询的效率是取决于auth字段，尽管totalIds查询速度快。

上述OR查询语句，索引扫描行数以及文档扫描行数均为18000多。

从中也可以看出，区分度高和低，影响的检索效率高低。

改进：

• 从业务角度，考虑将auth查询与非auth查询分开来查询，这样就不会有OR查询场景
• 从数据库的角度，可以考虑分两张表，当要查询auth=0还是1的时候，从小表查询；如果没有auth查询，就可以使用totalIds字段，由于其区分度高，可以大大提高检索效率。