MYSQL之pt-query-digest分析mysql负载性能问题
案例背景：
线上某台mysql生产库服务器，CPU负载告警，使用率持续接近100%，丝毫没有回落的意思！
1. 性能表象的数据采集
登陆DB服务器 ： 、mysql进程的CPU占用率765.9%(8核)，CPU基本上消耗殆尽!
2. 问题全面诊断：
结论：
内存，磁盘都不是问题，中断请求数还算可以接受，CPU出现性能瓶颈，有大量任务等待CPU时间片；
基本上可以断定是单纯的CPU问题，且是由于mysql进程引发；
根据CPU负载模型，可以断定出问题的地方：（用户态的CPU使用率是瓶颈）
1. mysql进行大量的内存操作，逻辑读；例如：缺失关键索引
2. 大量的CPU运算任务；例如：2表的笛卡尔积
3. MySQL层性能采集
此处可以考虑使用慢日志，由于磁盘不是瓶颈，不会带来太大的额外负载；
这里我采用tcpdump和pt-query-digest来抓问题SQL；
监控：
tcpdump -i eth0 -s 65535 -x -nn -q -tttt port 3306 -c 200000 > 1.dmp &
分析：
pt-query-digest --type tcpdump 1.dmp --limit 10 > report.log
基本上搞定TOP2SQL，问题就能得到缓解；
这2语句的执行时间基本是在1S的样子，且消耗了大量CPU时间：
SQL优化：
TOP 1 SQL
同一个表访问了N次，且是select *，想必大家都知道怎么优化了吧！（吐槽一下！）
TOP 2 SQL
该语句基本上是全表扫描，优化的余地不多；select * 是一个，建一个复合索引，使用索引扫描替换全表扫描
4. 解决办法
临时停止相应的业务，将优化方案提给开发部门！
线上某台mysql生产库服务器，CPU负载告警，使用率持续接近100%，丝毫没有回落的意思！
1. 性能表象的数据采集
登陆DB服务器 ： 、mysql进程的CPU占用率765.9%(8核)，CPU基本上消耗殆尽!
2. 问题全面诊断：
结论：
内存，磁盘都不是问题，中断请求数还算可以接受，CPU出现性能瓶颈，有大量任务等待CPU时间片；
基本上可以断定是单纯的CPU问题，且是由于mysql进程引发；
根据CPU负载模型，可以断定出问题的地方：（用户态的CPU使用率是瓶颈）
1. mysql进行大量的内存操作，逻辑读；例如：缺失关键索引
2. 大量的CPU运算任务；例如：2表的笛卡尔积
3. MySQL层性能采集
此处可以考虑使用慢日志，由于磁盘不是瓶颈，不会带来太大的额外负载；
这里我采用tcpdump和pt-query-digest来抓问题SQL；
监控：
tcpdump -i eth0 -s 65535 -x -nn -q -tttt port 3306 -c 200000 > 1.dmp &
分析：
pt-query-digest --type tcpdump 1.dmp --limit 10 > report.log
基本上搞定TOP2SQL，问题就能得到缓解；
这2语句的执行时间基本是在1S的样子，且消耗了大量CPU时间：
SQL优化：
TOP 1 SQL
同一个表访问了N次，且是select *，想必大家都知道怎么优化了吧！（吐槽一下！）
TOP 2 SQL
该语句基本上是全表扫描，优化的余地不多；select * 是一个，建一个复合索引，使用索引扫描替换全表扫描
4. 解决办法
临时停止相应的业务，将优化方案提给开发部门！