老王：最近我的MySQL数据库很慢.... 很忧伤，这可肿么办？

帅萌：老王，老王你莫心慌，听我跟你唠~

MySQL性能有问题，先应该关注的是慢查询日志（slow log）。

MySQL性能慢，多半是SQL引起的（慢查询日志会把执行慢的SQL，一五一十的记录下来，就像你的身体一样诚实..）需要根据慢查询日志的内容来优化SQL。

其次，除了MySQL慢查询日志，还需要更多的关注liunx系统的指标和参数。

top 命令帮你观察大橘(局)。

观察 load average 1分钟 、5分钟、 15分钟的平均负载值。

然后是us% 用户使用的CPU占比，如果us%太高，极有可能索引使用不当。sy%系统内核使用的CPU占比，如果sy%太高，要注意MySQL的连接数和锁等信息。wa% io使用CPU的占比，如果wa%太高，要关注MySQL是否使用了硬盘临时表，或者大量刷盘等操作，也有可能是硬盘太慢，或硬盘故障,可以使用iostat等工具来观察。

还需要关注各个逻辑CPU之前的负载是否均衡（可能是中断不均衡导致性能问题）,可以使用mpstat命令来进行详细观察。

MySQL是数据库服务，不建议跟其他应用混跑。

其次是内存的使用信息,先通过free来观察。

要观察 是否使用了SWAP，剩余多少内存，是否发生内存泄漏。

说到SWAP,就要说到NUMA，通过numactl来观察NUMA的使用情况，建议关闭NUMA。至于为什么，建议阅读《NUMA架构的CPU -- 你真的用好了么?》 。

阅读地址：

内存泄漏观察方法 buff/cache 和used 对比。 如果发生了内存泄漏，解决方案：

重启MySQL 。 升级到最新的小版本MySQL 。

还可以通过vmstat 来观察每秒的进程、内存、swap、io、cpu等详情情况。

然后要关注IO的使用情况,可以通过 iostat -x来观察，主要观察。

rrqm/s #每秒读取的扇区数。wrqm/s #每秒写入的扇区数。avgrq-sz #平均请求扇区的大小 。avgqu-sz #是平均请求队列的长度。await #每一个IO请求的相应时间。%util #在统计时间内所有处理IO时间，除以总共统计时,暗示了设备的繁忙程度。

MySQL观察层面

主要关注tps、qps、并发连接数(Threads_connected)、并发活跃线程数(Threads_running)、临时表(tmp_disk_tables)、锁(locks_waited, Innodb_row_lock*)等指标。关注当前是否有不良线程状态，例如：copyto tmp table、Creating sort index、Sorting result、Creating tmp table、长时间的Sending data等。关注InnoDB buffer pool page的使用情况，主要是Innodb pages_free、Innodb wait_free两个 。关注InnoDB的redo log刷新延迟，尤其是checkpoint延迟情况，并关注unpurge list大小。关注innodb status中是否有long semaphore wait的情况出现。观察是否有大事物的阻塞。

在观察MySQL运行状态方面，帅萌丢一个py脚本。写的时间久，迭代N个版本，不过这个版本很方便....（其他的在项目里拆起来有点费劲）。但是编程这方面越写越精，需要磨练，各位可以参考一下，相信你们会写的更棒（阅读原文，即可获取）。

如果实在看不懂的请联知数堂zizi老师，我负责挖坑，他负责教你会，带你飞。

代码地址：

还提供一个SOS.sh脚本，当性能遇到问题，可以根据实际情况进行修改，并自行把相关内容打包，以便探讨和交流。

（杨奇龙老师的图）

##参考 知数堂-叶问(20181218）

##感谢，有赞杨奇龙老师提供的帮助，以及图片支持。

关于「3306π」社区

围绕 MySQL 核心技术，将互联网行业中最重要的数据化解决方案带到传统行业中；囊括其他开源技术Redis、MongoDB、Hbase、Hadoop、ElasticSearch、Storm、Spark等；分享干货知识，即便是赞助商，也要求如此，拒绝放水。