MySQL CPU使用率高的排查与优化实战

梁培定

1. 问题现象与初步判断

最近在维护线上MySQL数据库时，突然收到监控系统告警：某台数据库服务器的CPU使用率持续超过90%，已经持续了半小时以上。这种异常情况如果不及时处理，轻则导致查询响应变慢，重则可能引发整个数据库的雪崩效应。

通过SSH连接到服务器后，我用top命令确认了CPU使用情况，发现确实是mysqld进程占用了大量CPU资源。这时候需要明确几个关键点：

是所有的CPU核心都满载还是某个核心特别高？
CPU的sys和user比例如何？
是否有大量的上下文切换(context switch)或中断(interrupt)？

在我的案例中，所有核心的使用率都比较均衡，user占比在85%以上，这说明确实是MySQL在处理查询消耗了大量计算资源，而不是系统层面的问题。

2. 排查工具与方法论

2.1 性能监控三板斧

遇到MySQL CPU高的问题，我通常会按照以下顺序排查：

SHOW PROCESSLIST
这是最直接的排查方法，可以查看当前正在执行的所有MySQL连接和查询。关键是要关注State列和Time列，找出那些长时间运行的查询。

sql复制SHOW FULL PROCESSLIST;

慢查询日志分析
如果processlist没有明显发现，就需要检查慢查询日志。需要确认slow_query_log是否开启，以及long_query_time的设置值。

sql复制SHOW VARIABLES LIKE 'slow_query%';
SHOW VARIABLES LIKE 'long_query_time';

性能模式(Performance Schema)
MySQL 5.6+版本提供的强大工具，可以获取更详细的性能数据。

sql复制-- 查看哪些SQL消耗最多CPU
SELECT * FROM sys.statement_analysis 
ORDER BY avg_latency DESC LIMIT 10;

2.2 进阶诊断工具

除了上述基本方法外，还有一些更专业的工具：

pt-query-digest：Percona提供的慢查询分析工具
mysqldumpslow：MySQL自带的慢查询分析工具
EXPLAIN：分析单条查询的执行计划
SHOW PROFILE：查看查询执行的详细资源消耗

3. 常见原因深度解析

3.1 索引问题导致的CPU高

这是最常见的原因之一。当查询没有使用合适的索引时，MySQL不得不进行全表扫描，这会消耗大量CPU资源。

典型案例：

缺少关键字段的索引
索引失效（如使用了函数、类型转换）
索引选择性差（如性别字段只有M/F两种值）

排查方法：

sql复制-- 查看表索引情况
SHOW INDEX FROM 表名;

-- 使用EXPLAIN分析查询
EXPLAIN SELECT * FROM users WHERE name LIKE '%张%';

解决方案：

为高频查询条件添加合适的索引
避免在索引列上使用函数
考虑使用复合索引

3.2 锁等待导致的CPU高

当大量查询因为锁等待而阻塞时，也会表现为CPU使用率高。这是因为这些查询虽然没有真正执行，但仍然占用着连接和资源。

排查方法：

sql复制-- 查看当前锁情况
SHOW ENGINE INNODB STATUS;

-- 查看等待锁的事务
SELECT * FROM sys.innodb_lock_waits;

解决方案：

优化事务大小，避免大事务
合理设置隔离级别
检查是否有热点行/表

3.3 配置不当导致的CPU高

MySQL的某些配置参数如果设置不当，也会导致CPU使用率异常。

常见配置问题：

join_buffer_size：过大导致内存和CPU浪费
sort_buffer_size：同上
tmp_table_size：频繁创建临时表
innodb_flush_log_at_trx_commit：设置为1时性能开销大

优化建议：

sql复制-- 查看当前配置
SHOW VARIABLES LIKE '%buffer%';
SHOW VARIABLES LIKE '%tmp%';

-- 建议根据服务器内存调整
SET GLOBAL join_buffer_size = 256K;
SET GLOBAL sort_buffer_size = 256K;

3.4 连接数过多

当并发连接数过多时，MySQL需要花费大量CPU资源在连接管理和上下文切换上。

排查方法：

sql复制-- 查看当前连接数
SHOW STATUS LIKE 'Threads_connected';

-- 查看最大连接数
SHOW VARIABLES LIKE 'max_connections';

解决方案：

优化应用连接池配置
考虑使用连接中间件（如ProxySQL）
实现读写分离

4. 实战案例分析

4.1 案例一：缺失索引导致的全表扫描

现象：
CPU持续90%+，processlist显示大量相同查询

排查过程：

通过SHOW PROCESSLIST发现大量类似查询：

sql复制SELECT * FROM orders WHERE user_id = ? AND status = 'pending'

检查表结构发现user_id有索引，但status没有
EXPLAIN确认查询使用了全表扫描

解决方案：

sql复制ALTER TABLE orders ADD INDEX idx_user_status (user_id, status);

效果：
CPU使用率从90%降至30%，查询速度提升10倍

4.2 案例二：错误配置导致的排序消耗

现象：
高峰时段CPU飙升，持续时间短但频繁

排查过程：

分析慢查询日志发现大量排序操作
检查发现sort_buffer_size设置为8MB（默认256K）
每个排序操作都分配8MB内存，导致频繁内存分配和CPU消耗

解决方案：

sql复制SET GLOBAL sort_buffer_size = 256K;

效果：
CPU峰值降低50%，内存使用更加稳定

5. 系统级优化建议

5.1 操作系统层面

确保MySQL运行在专用服务器上
调整内核参数（如swappiness、文件描述符限制）
使用性能更好的文件系统（如XFS）
考虑使用cgroups限制MySQL资源使用

5.2 硬件层面

使用SSD存储
确保足够的内存（建议是数据库大小的1.5倍）
CPU选择更多核心而非更高频率

5.3 MySQL配置优化

ini复制[mysqld]
# 缓冲池大小（总内存的70-80%）
innodb_buffer_pool_size = 12G

# 日志文件大小
innodb_log_file_size = 1G

# 并发线程数
innodb_thread_concurrency = 16

# 刷新方式
innodb_flush_method = O_DIRECT