sql执行快并不代表没有问题，排查一起“快”sql引发的数据库高负载
接到一起数据库故障，用户反馈主机cpu频繁告警，操作系统只安装了数据库，查看mysql后没有发现error日志，pt-query-digest分析最近1一个月的slow log，没有找到慢SQL。
数据库主机负载很高，但是找不到慢sql，那么原因出在哪了？
排查过程
-
perf top分析cpu高的函数
查看cpu耗时长的函数，都属于常规的大接口，除了软中断引发关注外，没发现其他异常函数调用。但是从这里可以看出，cpu资源几乎都被mysql服务使用了，且数据库负载较大。
-
查看show engine innodb status
这里再次印证了数据库高负载。如下图，数据库查询非常大，reads/s每秒查询达到了280万行，这已是普通虚拟机的极限了。
扩展
inserts/s、updates/s、deletes/s表示数据库TPS。一般好点的机器，TPS可以跑到4000多。
- 查看AHI信息
粗略计算，数据库AHI命中率约88%，这个值已经非常高了，所以也很好解释上文perf top中AHI相关函数调用高的问题。
- 查看fsync()调用执行情况
读写线程、缓冲池线程、日志线程均无IO受限情况，读、写和fsync()调用执行的数目也合理，这里没有问题。
总结
perf top分析cpu高的函数
查看cpu耗时长的函数，都属于常规的大接口，除了软中断引发关注外，没发现其他异常函数调用。但是从这里可以看出，cpu资源几乎都被mysql服务使用了，且数据库负载较大。
查看show engine innodb status
这里再次印证了数据库高负载。如下图，数据库查询非常大，reads/s每秒查询达到了280万行，这已是普通虚拟机的极限了。
扩展
inserts/s、updates/s、deletes/s表示数据库TPS。一般好点的机器，TPS可以跑到4000多。
粗略计算，数据库AHI命中率约88%，这个值已经非常高了，所以也很好解释上文perf top中AHI相关函数调用高的问题。
读写线程、缓冲池线程、日志线程均无IO受限情况，读、写和fsync()调用执行的数目也合理，这里没有问题。
