存储优化（三）：mongo 大表加索引
source link: https://mp.weixin.qq.com/s/8LQ-koSGiRjg35d0fDxi1g
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
摘要
在存储优化(2)-排序引起的慢查询优化中我们提到过排序对查询选择索引的影响。但是的解决办法就是增加一个索引。在线上给mongo的大表增加一个索引要慎重。在增加索引的过程中也遇到了一些问题，这边进行相关的记录与分析。
问题描述
表结构
索引
查询语句
增加一个索引
增加索引过程
对于大表（该表记录数5亿），建立索引过程涉及到锁表，大量的读写操作、数据同步，肯定会影响线上的操作。所以选择在业务低谷期，建立一个 background 的index,这样不会锁表。 注：
mongo4.2以后优化了建立索引过程，不需要background参数了https://docs.mongodb.com/manual/reference/command/createIndexes/#dbcmd.createIndexes
创建完索引后，通过客户端连接，查看执行计划，始终扫描一行。完美，走到了新的索引。
然后再观察几天慢sql，大吃一惊发现还是存在慢查询，但是相同的语句，放到客户端查询的时候，又是执行的新索引。查看system.profiles中慢日志
当时这条慢查询语句走的是 cached_plan . 
也就是说，走的是plan cache，已经缓存的执行计划。
那是不是因为这个索引是后来加的，plan-cache还没有更新的。清理掉执行计划缓存，执行操作
继续观察，发现并没有什么用。百思不得其解，在深入解析 MongoDB Plan Cache找到一些思路，MongoDB的执行计划
其中扫描N次中N是10倍的执行计划缓存的索引扫描次数。
看了下缓存计划中的
而该查询使用"bizId,version"索引，而bizId="xxxx"下面的索引值是100左右。我们的数据分布，bizId，version在100以内的可能是95%,只有5%的在100以上，这会给索引判断造成误判。
总结
最后解决是通过强制索引来避免索引误判，当然也可以将排序改成
这样也不会误判
总结一下：
-
大表加索引，需要确保不会block表的其他操作，尽量选择空闲时候，以background方式创建
-
增加完索引后，需要check索引是否发挥作用，只是通过explain有可能误判，还是需要结合数据库的slowlog来判断
-
同一个查询数据库也不总是使用一个索引，会根据查询情况进行调整。需要结合plan cache等情况来分析
-
修复数据库索引判断错误可以通过强制索引，或者调整语句引导数据库作出正确的判断。
参考
https://mongoing.com/archives/5624
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK