老王：最近我的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 -- 你真的用好了么?》 。
阅读地址：
http://t.cn/RAZ3hw9内存泄漏观察方法 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老师，我负责挖坑，他负责教你会，带你飞。
代码地址：
http://t.cn/E4n7O6S还提供一个SOS.sh脚本，当性能遇到问题，可以根据实际情况进行修改，并自行把相关内容打包，以便探讨和交流。
（杨奇龙老师的图）
、##参考 知数堂-叶问(20181218）
、##感谢，有赞杨奇龙老师提供的帮助，以及图片支持。