共计 1877 个字符，预计需要花费 5 分钟才能阅读完成。
如何解析 MySQL 性能瓶颈排查定位，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
导读
从一个现场说起，全程解析如何定位性能瓶颈。
排查过程
收到线上某业务后端的 MySQL 实例负载比较高的告警信息，于是登入服务器检查确认。
1. 首先我们进行 OS 层面的检查确认
登入服务器后，我们的目的是首先要确认当前到底是哪些进程引起的负载高，以及这些进程卡在什么地方，瓶颈是什么。
通常来说，服务器上最容易成为瓶颈的是磁盘 I / O 子系统，因为它的读写速度通常是最慢的。即便是现在的 PCIe SSD，其随机 I / O 读写速度也是不如内存来得快。当然了，引起磁盘 I / O 慢得原因也有多种，需要确认哪种引起的。
第一步，我们一般先看整体负载如何，负载高的话，肯定所有的进程跑起来都慢。
可以执行指令
某些进程 / 服务消耗更多 CPU 资源（服务响应更多请求或存在某些应用瓶颈）；
发生比较严重的 swap（可用物理内存不足）；
发生比较严重的中断（因为 SSD 或网络的原因发生中断）；
磁盘 I / O 比较慢（会导致 CPU 一直等待磁盘 I / O 请求）；
这时我们可以执行下面的命令来判断到底瓶颈在哪个子系统（横版查看）：
[yejr@imysql.com:~ ]# top
top - 11:53:04 up 702 days, 56 min, 1 user, load average: 7.18, 6.70, 6.47
Tasks: 576 total, 1 running, 575 sleeping, 0 stopped, 0 zombie
Cpu(s): 7.7%us, 3.4%sy, 0.0%ni, 77.6%id, 11.0%wa, 0.0%hi, 0.3%si, 0.0%st
Mem: 49374024k total, 32018844k used, 17355180k free, 115416k buffers
Swap: 16777208k total, 117612k used, 16659596k free, 5689020k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14165 mysql 20 0 8822m 3.1g 4672 S 162.3 6.6 89839:59 mysqld
40610 mysql 20 0 25.6g 14g 8336 S 121.7 31.5 282809:08 mysqld
49023 mysql 20 0 16.9g 5.1g 4772 S 4.6 10.8 34940:09 mysqld
很明显是前面两个 mysqld 进程导致整体负载较高。
而且，从 Cpu(s) 这行的统计结果也能看的出来，%us
一次请求读写的数据量太大，导致磁盘 I / O 读写值较大，例如一个 SQL 里要读取或更新几万行数据甚至更多，这种最好是想办法减少一次读写的数据量；
SQL 查询中没有适当的索引可以用来完成条件过滤、排序（ORDER BY）、分组（GROUP BY）、数据聚合（MIN/MAX/COUNT/AVG 等），添加索引或者进行 SQL 改写吧；
瞬间突发有大量请求，这种一般只要能扛过峰值就好，保险起见还是要适当提高服务器的配置，万一峰值抗不过去就可能发生雪崩效应；
因为某些定时任务引起的负载升高，比如做数据统计分析和备份，这种对 CPU、内存、磁盘 I / O 消耗都很大，最好放在独立的 slave 服务器上执行；
服务器自身的节能策略发现负载较低时会让 CPU 降频，当发现负载升高时再自动升频，但通常不是那么及时，结果导致 CPU 性能不足，抗不过突发的请求；
使用 raid 卡的时候，通常配备 BBU（cache 模块的备用电池），早期一般采用锂电池技术，需要定期充放电（DELL 服务器 90 天一次，IBM 是 30 天），我们可以通过监控在下一次充放电的时间前在业务低谷时提前对其进行放电，不过新一代服务器大多采用电容式电池，也就不存在这个问题了。
文件系统采用 ext4 甚至 ext3，而不是 xfs，在高 I / O 压力时，很可能导致 %util 已经跑到 100% 了，但 iops 却无法再提升，换成 xfs 一般可获得大幅提升；
内核的 io scheduler 策略采用 cfq 而非 deadline 或 noop，可以在线直接调整，也可获得大幅提升。
关于如何解析 MySQL 性能瓶颈排查定位问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注丸趣 TV 行业资讯频道了解更多相关知识。
