[MySQL优化案例]系列 — 典型性索引引发CPU负载飙升问题
收到一个mysql服务器负载告警,上去一看,load average都飙到280多了,用top一看,CPU跑到了336%,不过IO和内存的负载并不高,根据经验,应该又是一起索引引起的惨案了。
看下processlist以及slow query情况,发现有一个SQL经常出现,执行计划中的扫描记录数看着还可以,单次执行耗时为0.07s,还不算太大。乍一看,可能不是它引发的,但出现频率实在太高,而且执行计划看起来也不够完美:
mysql> explain SELECT count(1) FROM a , b WHERE a.id = b.video_id and b.state = 1 AND b.column_id = ’81’\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: b
type: index_merge
possible_keys: columnid_videoid,column_id,state,video_time_stamp,idx_videoid
key: column_id,state
key_len: 4,4
ref: NULL
rows: 100
Extra: Using intersect(column_id,state); Using where
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: a
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: b.video_id
rows: 1
Extra: Using where; Using index
再看下该表的索引情况:
mysql> show index from b\G
*************************** 1. row ***************************
Table: b
Non_unique: 0
Key_name: PRIMARY
Seq_in_index: 1
Column_name: id
Collation: A
Cardinality: 167483
Sub_part: NULL
Packed: NULL
Null:
Index_type: BTREE
Comment:
Index_comment:
*************************** 2. row ***************************
Table: b
Non_unique: 1
Key_name: column_id
Seq_in_index: 1
Column_name: column_id
Collation: A
Cardinality: 8374
Sub_part: NULL
Packed: NULL
Null:
Index_type: BTREE
Comment:
Index_comment:
*************************** 3. row ***************************
Table: b
Non_unique: 1
Key_name: state
Seq_in_index: 2
Column_name: state
Collation: A
Cardinality: 5
Sub_part: NULL
Packed: NULL
Null:
Index_type: BTREE
Comment:
Index_comment:
可以看到执行计划中,使用的是index merge,效率自然没有用联合索引(也有的叫做覆盖索引)来的好了,而且 state 字段的基数(唯一性)太差,索引效果很差。删掉两个独立索引,修改成联合看看效果如何:
mysql> show index from b;
*************************** 1. row ***************************
Table: b
Non_unique: 0
Key_name: PRIMARY
Seq_in_index: 1
Column_name: id
Collation: A
Cardinality: 128151
Sub_part: NULL
Packed: NULL
Null:
Index_type: BTREE
Comment:
Index_comment:
*************************** 2. row ***************************
Table: b
Non_unique: 1
Key_name: idx_columnid_state
Seq_in_index: 1
Column_name: column_id
Collation: A
Cardinality: 3203
Sub_part: NULL
Packed: NULL
Null:
Index_type: BTREE
Comment:
Index_comment:
*************************** 3. row ***************************
Table: b
Non_unique: 1
Key_name: idx_columnid_state
Seq_in_index: 2
Column_name: state
Collation: A
Cardinality: 3463
Sub_part: NULL
Packed: NULL
Null:
Index_type: BTREE
Comment:
Index_comment:
mysql> explain SELECT count(1) FROM a , b WHERE a.id = b.video_id and b.state = 1 AND b.column_id = ’81’ \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: b
type: ref
possible_keys: columnid_videoid,idx_videoid,idx_columnid_state
key: columnid_videoid
key_len: 4
ref: const
rows: 199
Extra: Using where
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: a
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: b.video_id
rows: 1
Extra: Using where; Using index
可以看到执行计划变成了只用到了 idx_columnid_state 索引,而且 ref 类型也变成了 const,SQL执行耗时也从0.07s变成了0.00s,相应的CPU负载也从336%突降到了12%不到。
总结下,从多次历史经验来看,如果CPU负载持续很高,但内存和IO都还好的话,这种情况下,首先想到的一定是索引问题,十有八九错不了。
--------------------------------------分割线--------------------------------------
知数堂 (http://zhishuedu.com)培训是由资深MySQL专家叶金荣、吴炳锡联合推出的专业优质培训品牌,主要有MySQL DBA实战优化和Python运维开发课程,是业内最有良心、最有品质的培训课程。
本文出自 “老叶茶馆” 博客,请务必保留此出处http://imysql.blog.51cto.com/1540006/1879883
[MySQL优化案例]系列 — 典型性索引引发CPU负载飙升问题相关推荐
- mysql表disable_[MySQL优化案例]系列 -- DISABLE/ENABLE KEYS的作用
[MySQL优化案例]系列 -- DISABLE/ENABLE KEYS的作用 作/译者:叶金荣 来源:http://imysql.cn 转载请注明作/译者和出处,并且不能用于商业用途,违者必究. 有 ...
- [MySQL优化案例]系列 — slave延迟很大优化方法
备注:插图来自网络搜索,如果觉得不当还请及时告知 :) 一般而言,slave相对master延迟较大,其根本原因就是slave上的复制线程没办法真正做到并发.简单说,在master上是并发模式(以In ...
- [MySQL优化案例]系列 -- OPTIMIZE的威力
作/译者:叶金荣(Email: ),来源:http://imysql.cn,转载请注明作/译者和出处,并且不能用于商业用途,违者必究. 1.先来看看多次删除插入操作后的表索引情况 mysql> ...
- mysql 优化 案例_[MySQL优化案例]系列 -- OPTIMIZE的威力
作/译者:叶金荣(Email: ),来源:http://imysql.cn,转载请注明作/译者和出处,并且不能用于商业用途,违者必究. 1.先来看看多次删除插入操作后的表索引情况 mysql> ...
- [MySQL优化案例]系列 -- 用TIMESTAMP类型取代INT和DATETIME
引言:在以前,我总是习惯用 INT UNSIGNED 来存储一个转换成Unix时间戳的时间值,认为这样做从索引,比较等角度来讲,都会比较高效.现在我们来对比下 TIMESTAMP 和 INT UNSI ...
- [MySQL优化案例]系列 -- 试用TCMalloc
作/译者:叶金荣(Email: ),来源:http://imysql.cn,转载请注明作/译者和出处,并且不能用于商业用途,违者必究. TCMalloc 是用于优化C++写的多线程应用,比glibc ...
- [MySQL优化案例]系列 -- DISABLE/ENABLE KEYS的作用
作/译者:叶金荣(Email: ),来源:http://imysql.cn,转载请注明作/译者和出处,并且不能用于商业用途,违者必究. 有一个表 tbl1 的结构如下: CREATE TABLE `t ...
- 【MySQL优化(六)】InnoDB索引优化与索引规约
序 上一篇讲解了建表规范后,本章重点分析下创建索引的一些规范 由于索引是工作在存储引擎层,所以以下规约都是基于InnoDB引擎 题外话 在满足语句需求的情况下, 尽量少地访问/消耗资源是数据库设计的重 ...
- 【MySQL】故障分析 | MySQL 优化案例 - 字符集转换
1.概述 好文章转载:故障分析 | MySQL 优化案例 - 字符集转换 一.背景 开发联系我,说是开发库上有一张视图查询速度很慢,9000 条数据要查 10s,要求我这边协助排查优化. 二.问题 S ...
最新文章
- 什么是泛型缓存和静态构造函数?
- Oracle 维护数据的完整性 一 索引
- 拼车日滴滴派单的那些事
- python怎么显示汉字_mac在matplotlib中显示中文的操作方法
- .NET Core开发日志——结构化日志
- 你永远都不知道你老公可以多幼稚......
- 3.3、自定义错误页面
- kafka 重新分配节点_Kafka扩容节点和分区迁移
- iOS模型输出和打印
- 【激活函数】h-swish激活函数详解
- 图结构 计算机视觉,探索图结构数据上的数据增强
- 知识表示-马尔科夫链(MC)
- 批量发送邮件的软件——邮件群发机器人
- Python TODO说明
- 如果牛顿是程序员,那么?
- 苹果6运行内存是多少_iPhone 12为什么不标注运行内存?安卓转苹果手机是入11还是入12呢?...
- C语言从小到大进行排序
- 【小5聊】使用div+css布局绘制32支球队比赛对阵图,拭目以待冠军花落谁家
- WINDOWS WIA 驱动开发 0x80210015,0x80210016错误
- 35岁前多用利弊分析,35岁后要有“安全边际”
热门文章
- python 左旋转字符串
- 面向过程和面向对象的区别
- nacos 配置不会动态刷新_Alibaba之Nacos详解
- extjs获取焦点和失去焦点_[NBA夏联]焦点单三连红,NBA夏季联赛同样精彩
- 【Go】从键盘输入字符串和数字
- openssl1.1.0 支持php,openssl升级到1.0.21以支持nginx http2 ssl
- 移动端像素概念,viewport,适配
- win7 X64 编译ffmpeg
- 【Linux】30.ssh不用手动输入密码登录终端sshpass 和 shell脚本后跟参数自动匹配case的用法
- Spring的7种事务传播行为类型