在存储优化(2)-排序引起的慢查询优化中我们提到过排序对查询选择索引的影响。但是的解决办法就是增加一个索引。在线上给mongo的大表增加一个索引要慎重。在增加索引的过程中也遇到了一些问题,这边进行相关的记录与分析。
表结构
_id,biz_Id,version,name
索引
1. 主键索引2. biz_id,version联合索引
查询语句
"query":{"find":"historyRecord","filter":{"bizId":1234567},"sort":{"_id":-1},"limit":1}}
增加一个索引
bizId,_id
对于大表(该表记录数5亿),建立索引过程涉及到锁表,大量的读写操作、数据同步,肯定会影响线上的操作。所以选择在业务低谷期,建立一个background的index,这样不会锁表。注:
mongo4.2以后优化了建立索引过程,不需要background参数了https://docs.mongodb.com/manual/reference/command/createIndexes/#dbcmd.createIndexes
创建完索引后,通过客户端连接,查看执行计划,始终扫描一行。完美,走到了新的索引。
"executionStats" : { "executionSuccess" : true, "nReturned" : 1, "executionTimeMillis" : 0, "totalKeysExamined" : 1, "totalDocsExamined" : 1
然后再观察几天慢sql,大吃一惊发现还是存在慢查询,但是相同的语句,放到客户端查询的时候,又是执行的新索引。查看system.profiles中慢日志
当时这条慢查询语句走的是cached_plan.
也就是说,走的是plan cache,已经缓存的执行计划。
那是不是因为这个索引是后来加的,plan-cache还没有更新的。清理掉执行计划缓存,执行操作
db.historyRecord.getPlanCache().clear()
继续观察,发现并没有什么用。百思不得其解,在深入解析 MongoDB Plan Cache找到一些思路,MongoDB的执行计划
其中扫描N次中N是10倍的执行计划缓存的索引扫描次数。
看了下缓存计划中的
db.getCollection('historyRecord').getPlanCache().listQueryShapes() { "query" : { "bizId" : "xxxxx" }, "sort" : 0 "_id" : -1.0 }, "projection" : {} },
而该查询使用"bizId,version"索引,而bizId="xxxx"下面的索引值是100左右。我们的数据分布,bizId,version在100以内的可能是95%,只有5%的在100以上,这会给索引判断造成误判。
最后解决是通过强制索引来避免索引误判,当然也可以将排序改成
sort({bizId:-1,_id:-1})
这样也不会误判
总结一下:
https://mongoing.com/archives/5624