MySQL CPU使用率飙升排查与优化实战-代码聚汇网

MySQL CPU使用率飙升排查与优化实战

鄂奎阿·2026-07-09·阅读 39 GEO检测（免费）

MySQL性能优化CPU使用率高慢查询分析

|难度：普通|阅读约 13 分钟

1. MySQL CPU 使用率飙升的常见表现

当MySQL服务器的CPU使用率异常升高时，通常会在以下几个方面表现出明显异常：

系统监控工具（如top、htop）显示mysqld进程持续占用高CPU资源
数据库响应时间显著变慢，简单查询也可能出现延迟
连接数可能激增，出现"Too many connections"错误
慢查询日志中突然出现大量新增记录
系统负载平均值（load average）持续高于CPU核心数

我曾处理过一个电商平台的案例，在促销活动期间CPU使用率突然从平时的30%飙升至95%，导致订单提交接口超时。通过以下排查方法，最终发现是一个未优化的商品搜索查询引起的。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 排查高CPU使用率的系统级方法

2.1 使用top命令定位问题进程

首先通过top命令确认确实是mysqld进程导致CPU过高：

bash复制top -c -o %CPU

在输出中观察：

%CPU列显示mysqld进程的CPU占用率
查看RES内存占用是否也异常
记录进程ID用于后续分析

提示：按"P"可以按CPU排序，按"M"可以按内存排序

2.2 检查MySQL全局状态

连接MySQL后执行：

sql复制SHOW GLOBAL STATUS LIKE 'Threads_running';
SHOW GLOBAL STATUS LIKE 'Questions';
SHOW GLOBAL STATUS LIKE 'Slow_queries';

这些指标可以帮助判断：

当前活跃线程数是否异常
查询频率是否突然增加
慢查询数量是否激增

2.3 分析进程列表

sql复制SHOW PROCESSLIST;

或者更详细的版本：

sql复制SELECT * FROM information_schema.processlist 
WHERE COMMAND != 'Sleep' 
ORDER BY TIME DESC;

重点关注：

执行时间(TIME)过长的查询
状态(State)为"Sending data"、"Copying to tmp table"等耗时操作
相同的查询模板重复出现

3. 查询级别的深度排查

3.1 启用和解析慢查询日志

在my.cnf中配置：

ini复制slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 1
log_queries_not_using_indexes = 1

分析慢日志：

bash复制mysqldumpslow -s t /var/log/mysql/mysql-slow.log

常见参数：

-s t：按总时间排序
-s l：按锁定时间排序
-s at：按平均时间排序

3.2 使用EXPLAIN分析问题查询

对可疑查询执行EXPLAIN：

sql复制EXPLAIN SELECT * FROM orders WHERE user_id = 100 AND status = 'pending';

重点关注：

type列：最好达到ref或range级别，避免ALL(全表扫描)
possible_keys/key：是否使用了合适的索引
rows：预估扫描行数
Extra：是否有"Using filesort"、"Using temporary"等警告

3.3 性能模式(Performance Schema)分析

MySQL 5.6+版本可以使用：

sql复制-- 查看最耗CPU的语句
SELECT digest_text, sum_timer_wait/1000000000 as sec 
FROM performance_schema.events_statements_summary_by_digest 
ORDER BY sum_timer_wait DESC LIMIT 10;

-- 查看全表扫描的语句
SELECT query, exec_count, rows_examined/exec_count as rows_per_exec
FROM sys.statements_with_full_table_scans
LIMIT 10;

4. 常见高CPU问题的解决方案

4.1 索引缺失或不当

案例：用户表没有为status字段建立索引，导致筛选查询全表扫描

解决方案：

sql复制ALTER TABLE users ADD INDEX idx_status (status);

索引设计原则：

为WHERE、JOIN、ORDER BY、GROUP BY中的字段建索引
使用复合索引时遵循最左前缀原则
避免在索引列上使用函数

4.2 查询写法问题

常见问题查询：

sql复制-- 使用OR导致索引失效
SELECT * FROM products WHERE category = 'electronics' OR price > 1000;

-- 优化方案
SELECT * FROM products WHERE category = 'electronics'
UNION
SELECT * FROM products WHERE price > 1000;

其他优化技巧：

避免SELECT *，只查询需要的列
分页查询使用LIMIT加偏移量要谨慎
避免在WHERE子句中对字段使用函数

4.3 连接池和配置优化

调整关键参数：

ini复制innodb_buffer_pool_size = 4G  # 通常设为物理内存的50-70%
innodb_log_file_size = 256M
max_connections = 200
thread_cache_size = 50
table_open_cache = 2000

连接池建议：

应用端使用连接池（如HikariCP）
设置合理的连接超时时间
监控连接数变化

4.4 临时表和文件排序优化

当出现"Using temporary; Using filesort"时：

优化GROUP BY和ORDER BY子句，使其使用索引
增大tmp_table_size和max_heap_table_size
考虑使用派生表替代临时表

5. 高级诊断工具和技术

5.1 pt-query-digest分析

Percona Toolkit中的强大工具：

bash复制pt-query-digest /var/log/mysql/mysql-slow.log

输出包括：

查询响应时间分布
执行频率
表扫描情况
索引使用建议

5.2 MySQL Enterprise Monitor

商业工具提供：

实时性能监控
异常检测
自动化顾问建议
历史数据分析

5.3 使用OPTIMIZER_TRACE

对于复杂查询，可以启用优化器跟踪：

sql复制SET optimizer_trace="enabled=on";
SELECT * FROM ...;  -- 执行问题查询
SELECT * FROM information_schema.optimizer_trace;
SET optimizer_trace="enabled=off";

6. 预防性维护策略

6.1 定期检查清单

每周检查未使用索引：

sql复制SELECT * FROM sys.schema_unused_indexes;

每月分析表：

sql复制ANALYZE TABLE important_table;

监控索引统计信息：

sql复制SELECT * FROM mysql.innodb_index_stats;

6.2 自动化监控方案

推荐监控项：

CPU使用率阈值告警（如>80%持续5分钟）
活跃线程数监控
慢查询率（慢查询/总查询）
InnoDB缓冲池命中率

工具选择：

Prometheus + Grafana
Percona Monitoring and Management
Datadog/New Relic等APM工具

6.3 压力测试和基准测试

使用工具：

sysbench：综合性能测试
mysqlslap：查询负载测试
jMeter：应用层压力测试

测试要点：

模拟生产数据量
包含高峰时段负载模式
测试前后记录性能指标

7. 特殊场景处理经验

7.1 突发流量导致CPU飙升

处理步骤：

临时增加连接池大小
启用读写分离分流读请求
对非关键功能降级
快速定位热点查询并优化

7.2 批量作业优化

对于大批量操作：

拆分为小批次提交
在低峰期执行
禁用无关索引和约束
使用LOAD DATA替代INSERT

7.3 云数据库的特殊考量

云上MySQL注意：

实例规格与负载匹配
监控IOPS限制
只读实例扩展读能力
合理设置自动扩展策略

我在实际运维中发现，大约60%的CPU高负载问题可以通过优化前10个最耗资源的查询来解决。关键是要建立持续监控机制，在问题影响用户前就能发现并处理。对于核心业务表，建议在开发阶段就进行查询性能评审，比事后优化更有效。