前言:

     收到疯狂的慢查询及请求超时报警,通过metrics分析出来自mysql请求的异常,cli —> show proceslist 看到很多慢查询。 先前该sql是没有的,后面因为数据量的增长才出现了这问题。 虽然feeds表大到一个亿,但因为feeds流信息有近期热的特征,所以不是因为 innodb_buffer_pool_size 低效引起的io频繁。 后来经过进一步explain执行计划分析得出了原因,mysql查询优化器选择了他认为高效的索引。


mysql查询优化器大多数情况是靠谱的!  但是你的sql语言含有多个索引时就要注意了,往往最后的结果令人有些彷徨了。因为mysql同一个sql只能使用一个索引,那么选择哪个呢? 在数据量小时候,mysql优化器会把主键索引后置,优先使用 index和unique 。 当你达到一个数据量级后,又因为你的查询操作有 in ,那么mysql查询优化器很可能会选用主键的 !


记住一句话,mysql查询优化是基于检索成本考虑,而不是基于时间成本考虑。 优化器是根据现有的数据状态来推算代价,而不是真的去执行一遍sql.


所以,mysql优化器并不是每次都可以达到优化的效果的。 它并不能准确预估代价,如果要准确得到走各个索引的代价就要去真的执行一遍才能知道,所以代价分析只是做了一个预估,既然是预估那么就有误判。


该文章写的有些乱,欢迎来喷 ! 另外文章后续不断更新中,请到原文地址查看更新.   http://xiaorui.cc/?p=4342


我们这里说的表是feed信息流表,我们知道feeds信息流表访问不仅频繁,而且数据量也很大。 但是这个表的数据结构很简单,索引也简单.   一共就两个索引,一个是主键索引, 一个是unique唯一键索引。

如下,该表的量级已经到亿级别了,因为有足够多的cache前顶,又因为这样那样的原因,所以没来的及做分库分表。

问题是这样的, 当数据量级不到一个亿的时候,mysql优化器选择使用 index索引, 当数据量级超过一个亿后,mysql查询优化器选择使用 主键索引了。  这样带来的问题就是 查询速度太慢。


这是正常情况下:

同样的sql语句,在数据量有较大变化后,mysql查询优化器对索引的选择也有了变化。

那么解决方法是使用 force index,强制查询优化器使用我们给出的index 。 我这里是python开发环境,常见的python orm都有force index,ignore index,user index 参数的。 

那么我们应该怎么预防这种 因为数据的增进,mysql优化器选择了一个低效索引的问题呢?

针对这个问题请教了几个厂的dba,得到的答案和我们的方法是一样的。 都是只能通过后期的慢查询来发现问题,然后在sql语句中指定force index来解决索引问题。 另外,在系统上线初期就会做这类问题的规避,但往往业务开发人员初期都会配合dba们的审查工作,但后期为了省事,或者说自以为是认为没有问题,所以造成了 mysql查询事故。

我自己对于mysql优化器选择索引规则一知半解的,后面准备花时间好好研究下规则, 更多 http://xiaorui.cc

推荐书籍:

数据库查询优化器的艺术- 李海翔

END.



对Python及运维开发感兴趣的朋友可以加QQ群 : 478476595 !!!
{ 2000人qq大群内有各厂大牛,常组织线上分享及沙龙,对高性能及分布式场景感兴趣同学欢迎加入该QQ群 }

另外如果大家觉得文章对你有些作用!   帮忙点击广告. 一来能刺激我写博客的欲望,二来好维护云主机的费用.
如果想赏钱,可以用微信扫描下面的二维码. 另外再次标注博客原地址  xiaorui.cc  ……   感谢!

让人无语的MySQL嵌套事务

      MySQL是支持嵌套事务的,但是没多少人会这么干的…. 前段时间在国外看到一些老外在争论MySQL嵌套事务的场景必要性。 逗死我了,...

阅读全文

为什么不建议innodb使用亿级大表

上下文:        在Facebook上看到了一个比较新颖的mysql技术话题, 为什么不推荐在mysql下使用大表 , 或者说 什么情况下可以...

阅读全文

关于mysql分库分表及高可用集群经验 [下]

承接上个话题 … …   本想是切分成上中下章节的,但实在不想过于的拖拉,索性利索点的完成该话题。   mysql分库分表话题整理的有点乱...

阅读全文