存储优化(三):mongo 大表加索引

栏目: IT技术 · 发布时间: 4年前

内容简介:在存储优化(2)-排序引起的慢查询优化中我们提到过排序对查询选择索引的影响。但是的解决办法就是增加一个索引。在线上给mongo的大表增加一个索引要慎重。在增加索引的过程中也遇到了一些问题,这边进行相关的记录与分析。表结构索引

摘要

在存储优化(2)-排序引起的慢查询优化中我们提到过 排序 对查询选择索引的影响。但是的解决办法就是增加一个索引。在线上给mongo的大表增加一个索引要慎重。在增加索引的过程中也遇到了一些问题,这边进行相关的记录与分析。

问题描述

表结构

索引

查询语句

增加一个索引

增加索引过程

对于大表(该表记录数5亿),建立索引过程涉及到锁表,大量的读写操作、数据同步,肯定会影响线上的操作。所以选择在业务低谷期,建立一个 background 的index,这样不会锁表。 注:

mongo4.2以后优化了建立索引过程,不需要background参数了https://docs.mongodb.com/manual/reference/command/createIndexes/#dbcmd.createIndexes

创建完索引后,通过客户端连接,查看执行计划,始终扫描一行。完美,走到了新的索引。

然后再观察几天慢sql,大吃一惊发现还是存在慢查询,但是相同的语句,放到客户端查询的时候,又是执行的新索引。查看system.profiles中慢日志

当时这条慢查询语句走的是 cached_plan . 存储优化(三):mongo 大表加索引 也就是说,走的是plan cache,已经缓存的执行计划。

那是不是因为这个索引是后来加的,plan-cache还没有更新的。清理掉执行计划缓存,执行操作

继续观察,发现并没有什么用。百思不得其解,在深入解析 MongoDB Plan Cache找到一些思路,MongoDB的执行计划

存储优化(三):mongo 大表加索引 其中扫描N次中N是10倍的执行计划缓存的索引扫描次数。

看了下缓存计划中的

而该查询使用"bizId,version"索引,而bizId="xxxx"下面的索引值是100左右。我们的数据分布,bizId,version在100以内的可能是95%,只有5%的在100以上,这会给索引判断造成误判。

总结

最后解决是通过强制索引来避免索引误判,当然也可以将排序改成

这样也不会误判

总结一下:

  1. 大表加索引,需要确保不会block表的其他操作,尽量选择空闲时候,以background方式创建

  2. 增加完索引后,需要check索引是否发挥作用,只是通过explain有可能误判,还是需要结合数据库的slowlog来判断

  3. 同一个查询数据库也不总是使用一个索引,会根据查询情况进行调整。需要结合plan cache等情况来分析

  4. 修复数据库索引判断错误可以通过强制索引,或者调整语句引导数据库作出正确的判断。

参考

https://mongoing.com/archives/5624


以上所述就是小编给大家介绍的《存储优化(三):mongo 大表加索引》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Django 1.0 Template Development

Django 1.0 Template Development

Scott Newman / Packt / 2008 / 24.99

Django is a high-level Python web application framework designed to support the rapid development of dynamic websites, web applications, and web services. Getting the most out of its template system a......一起来看看 《Django 1.0 Template Development》 这本书的介绍吧!

HTML 压缩/解压工具
HTML 压缩/解压工具

在线压缩/解压 HTML 代码

html转js在线工具
html转js在线工具

html转js在线工具

RGB HSV 转换
RGB HSV 转换

RGB HSV 互转工具