tcpdump&pt-query-digest分析mysql负载性能问题

原文地址：
[MySQL运维] 生产数据库性能优化真实案例
http://f.dataguru.cn/forum.php?mod=viewthread&action=printable&tid=361155

案例背景

线上某台mysql生产库服务器，CPU负载告警，使用率持续接近100%，丝毫没有回落的意思！

性能表象的数据采集

登陆DB服务器
mysql进程的CPU占用率765.9%(8核)，CPU基本上消耗殆尽!

问题全面诊断

结论：
内存，磁盘都不是问题，中断请求数还算可以接受，CPU出现性能瓶颈，有大量任务等待CPU时间片；
基本上可以断定是单纯的CPU问题，且是由于mysql进程引发；
根据CPU负载模型，可以断定出问题的地方：（用户态的CPU使用率是瓶颈）
1. mysql进行大量的内存操作，逻辑读；例如：缺失关键索引
2. 大量的CPU运算任务；例如：2表的笛卡尔积

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 * 是一个，建一个复合索引，使用索引扫描替换全表扫描

解决办法

临时停止相应的业务，将优化方案提给开发部门！