MYSQL服务器中单个CPU占用过高问题的定位与解决

一次对某查询交易性能测试执行过程中，通过nmon监控指标发现MySQL数据库服务器的某个CPU的占用一直是99%左右。

本次数据库的资源配置为4C8G，另外三个CPU的使用率为0，对于MySQL单核CPU占用过高问题进行了分析调优过程。

01

确认io_thread的参数设置，通过执行：

show variables like 'innodb_read_io_threads';

（左右滑动查看完整代码）

show variables like 'innodb_write_io_threads';

（左右滑动查看完整代码）

查询出read和write的thread设置都是8，因此笔者认为这并不是CPU占用过高的根本原因。

02

通过pidstat -upidstat来判断是否利用到多核CPU，确认MySQL是可以利用到多核CPU。

通过以上排查，可以看出MySQL数据库本身的设置不是造成单核cpu过高的问题，那么是不是查询语句的问题呢？

03

检查sql语句的执行情况以及数据库是否存在锁的问题，我们可以用到MySQL提供的information_schema来进行性能的故障排除。

innodb_trx表是MySQL提供的information_schema中的一张表，INNODB_TRX 表提供有关当前在innodb内部的每个事务的信息，包括事务是否正在等待锁、事务何时开始以及事务正在执行的SQL语句，必须有procrss特权才能查询该表。

04

通过 SELECT * FROM information_schema.INNODB_TRX来检查系统是否有反复执行的交易，特别注意的是nnodb_trx这张表，它不是一张历史记录表，而是只记录当前正在执行中的事务，所以要在执行过程中进行跟踪。

在服务器中查到有若干sql语句处于running状态，借助MySQL慢查询日志来逐一排查正在执行的sql语句。

long_query_time

MySQL的慢查询，全名是慢查询日志，是MySQL提供的一种日志记录，用来记录在MySQL中响应时间超过阈值的语句具体环境中，运行时间超过long_query_time值的SQL语句，则会被记录到慢查询日志中。

long_query_time的默认值为10，默认情况下，MySQL数据库并不启动慢查询日志，需要手动来设置这个参数。

set global slow_query_log=1可以开启慢查询日志，但是只对当前数据库生效，MySQL重启后则会失效。如下：

 mysql> show variables  like '%slow_query_log%'; +---------------------+-----------------------------------------------+ | Variable_name       | Value                                          +---------------------+-----------------------------------------------+ | slow_query_log      | OFF                                            | slow_query_log_file | /home/WDPM/MysqlData/mysql/DB-Server-slow.log  +---------------------+-----------------------------------------------+ 2 rows in set (0.00 sec) mysql> set global slow_query_log=1;

（左右滑动查看完整代码）

global long_query_time

通过mysql> set global long_query_time=2;来设置超过该运行时间（s）的sql会被记录，我们设置了查询超过2秒就会被记录。

Slow_queries

可以使用Slow_queries系统变量。查询有多少条慢查询记录。

设置慢查询日志存放的位置

mysql> set global slow_query_log_file='/usr/local/mysql/data/slow.log';

（左右滑动查看完整代码）

mysqldumpslow工具

MySQL提供了日志分析工具mysqldumpslow，可以分析sql语句的数量等情况，根据自己的需要。

比如，得到返回记录集最多的5个SQL：

mysqldumpslow -s r -t 5 /database/mysql/mysql06_slow.log

（左右滑动查看完整代码）

得到访问次数最多的5个SQL：

mysqldumpslow -s c -t 5 /database/mysql/mysql06_slow.log

（左右滑动查看完整代码）

通过借助慢查询日志，我们发现有6条sql的执行记录运行时间很长，甚至存在140000秒的记录。

通过开发测试人员的分析，发现有部分数据表未设置索引，有的虽然设置了主键索引，但是忽略了where条件里的字段并未设置索引，导致查询时间过长。

发现上述问题后，开发人员更新设置索引情况，同时将查询热表的sql语句按时间区间进行优化，再次执行性能测试并监控，发现CPU的性能分布均匀在4核，平均cpu的使用率为35%，sql的执行时间也大大缩减。

以上就是我在MYSQL性能测试及调优过程的经验。

End

Have Fun ~ Tester ！

• FunTester测试框架架构图初探
• 10万QPS，K6、Gatling和FunTester终极对决！
• 环境基础【FunTester框架教程】
• 生产环境中进行自动化测试
• 小白自动化测试指南
• 成为自动化测试的7种技能
• Selenium4前线快报
• 测试为何会错过Bug
• httpclient使用HTTP代理实践
• Socket.IO接口多用户测试实践
• 无数据驱动自动化测试
• 从Java到Groovy的八级进化论
• Selenium 4以后，再不相见的API

点击阅读阅文，查看FunTester历史原创集合

- END -

戳 “阅读原文”一起来充电吧!

本文分享自微信公众号 - FunTester（NuclearTester）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。