记一次因线上mysql优化器误判引起慢查询事件
作者:rfyiamcool 时间:2024-01-26 18:14:41
前言:
收到疯狂的慢查询及请求超时报警,通过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优化器并不是每次都可以达到优化的效果的。 它并不能准确预估代价,如果要准确得到走各个索引的代价就要去真的执行一遍才能知道,所以代价分析只是做了一个预估,既然是预估那么就有误判。
我们这里说的表是feed信息流表,我们知道feeds信息流表访问不仅频繁,而且数据量也很大。 但是这个表的数据结构很简单,索引也简单. 一共就两个索引,一个是主键索引, 一个是unique唯一键索引。
如下,该表的量级已经到亿级别了,因为有足够多的cache前顶,又因为这样那样的原因,所以没来的及做分库分表。
问题是这样的, 当数据量级不到一个亿的时候,mysql优化器选择使用 index索引, 当数据量级超过一个亿后,mysql查询优化器选择使用 主键索引了。 这样带来的问题就是 查询速度太慢。
这是正常情况下:
mysql> explain SELECT * FROM `feed` WHERE user_id IN (116537309,116709093,116709377) AND cid IN (1001,1005,1054,1092,1093,1095) AND id <= 128384713 ORDER BY id DESC LIMIT 0, 11 \G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: feed
partitions: NULL
type: range
possible_keys: PRIMARY,feed_user_target
key: feed_user_target
key_len: 6
ref: NULL
rows: 18
filtered: 50.00
Extra: Using where; Using index; Using filesort
1 row in set, 1 warning (0.00 sec)
同样的sql语句,在数据量有较大变化后,mysql查询优化器对索引的选择也有了变化。
mysql> explain SELECT * FROM `feed` WHERE user_id IN (116537309,116709093,116709377) AND cid IN (1001,1005,1054,1092,1093,1095) AND id <= 128384713 ORDER BY id DESC LIMIT 0, 11 \G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: feed
type: range
possible_keys: PRIMARY,feed_user_target
key: PRIMARY
key_len: 4
ref: NULL
rows: 11873197
Extra: Using where
1 row in set (0.00 sec)
那么解决方法是使用 force index,强制查询优化器使用我们给出的index 。 我这里是python开发环境,常见的python orm都有force index,ignore index,user index 参数的。
explain SELECT * FROM `feed` force index (feed_user_target) WHERE user_id IN (116537309,116709093,116709377) ...
那么我们应该怎么预防这种 因为数据的增进,mysql优化器选择了一个低效索引的问题呢?
针对这个问题请教了几个厂的dba,得到的答案和我们的方法是一样的。 都是只能通过后期的慢查询来发现问题,然后在sql语句中指定force index来解决索引问题。 另外,在系统上线初期就会做这类问题的规避,但往往业务开发人员初期都会配合dba们的审查工作,但后期为了省事,或者说自以为是认为没有问题,所以造成了 mysql查询事故。
我自己对于mysql优化器选择索引规则一知半解的,后面准备花时间好好研究下规则
![](/images/zang.png)
![](/images/jiucuo.png)
猜你喜欢
基于Pyinstaller打包Python程序并压缩文件大小
![](https://img.aspxhome.com/file/2023/9/110539_0s.jpg)
go zero微服务实战性能优化极致秒杀
![](https://img.aspxhome.com/file/2023/4/86304_0s.jpg)
网站登录持久化Cookie方案
pytorch从头开始搭建UNet++的过程详解
![](https://img.aspxhome.com/file/2023/9/132369_0s.jpg)
Tensorflow中的dropout的使用方法
![](https://img.aspxhome.com/file/2023/6/127936_0s.png)
mysql数据库你需要特别注意的23个事项
python使用psutil模块获取系统状态
Java基础MAC系统下IDEA连接MYSQL数据库JDBC过程
![](https://img.aspxhome.com/file/2023/1/128841_0s.png)
机器学习python实战之决策树
![](https://img.aspxhome.com/file/2023/2/107642_0s.png)
ASP给长的标题加省略号...
JavaScript数据结构和算法之图和图算法
![](https://img.aspxhome.com/file/2023/8/129608_0s.jpg)
Python EOL while scanning string literal问题解决方法
![](https://img.aspxhome.com/file/2023/2/133462_0s.png)
Python反爬实战掌握酷狗音乐排行榜加密规则
![](https://img.aspxhome.com/file/2023/5/70245_0s.gif)
django+xadmin+djcelery实现后台管理定时任务
![](https://img.aspxhome.com/file/2023/5/97325_0s.png)
php实现mysql同步的实现方法
手写个小组件(组件入门)asp版
Python实现图像去噪方式(中值去噪和均值去噪)
![](https://img.aspxhome.com/file/2023/5/75915_0s.jpg)
Python数据结构之链表详解
![](https://img.aspxhome.com/file/2023/6/80796_0s.png)
Python实现合并两个有序链表的方法示例
![](https://img.aspxhome.com/file/2023/0/75250_0s.png)
SQL获取第一条记录的方法(sqlserver、oracle、mysql数据库)
![](https://img.aspxhome.com/file/2023/4/113554_0s.png)