首页 >> 基础教程

MySQL 导致 cpu 飙升的话，要怎么处理呢？

MySQL 导致 CPU 飙升是一个常见但棘手的问题，需要系统性地排查和优化。以下是我总结的处理步骤和关键点，帮助你快速定位并解决问题：

使用 KILL [id] 终止消耗资源的查询（谨慎操作）。

慢查询分析（最常见原因）
开启慢查询日志
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1; -- 设置超过1秒为慢查询 SET GLOBAL slow_query_log_file = '/path/to/slow.log';
分析慢日志
mysqldumpslow -s t /path/to/slow.log # 按耗时排序 pt-query-digest /path/to/slow.log # 推荐使用 Percona Toolkit
检查锁争用
SHOW ENGINE INNODB STATUS; -- 查看 "TRANSACTIONS" 和 "SEMAPHORES" 部分
关注 innodb_row_lock_waits 和锁等待线程。
索引失效或缺失
检查执行计划
EXPLAIN SELECT ...; -- 分析高消耗SQL的执行计划重点观察：type（扫描方式）、key（使用的索引）、rows（扫描行数）。
缺失索引检查
SELECT * FROM sys.schema_unused_indexes; -- 需先启用 performance_schema
配置与资源问题
检查关键参数
SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; -- 内存是否过小？ SHOW VARIABLES LIKE 'max_connections'; -- 连接数是否过多？
监控资源瓶颈
vmstat 1 # 看上下文切换(cs)和阻塞(b) iostat -dx 1 # 磁盘IO是否成为瓶颈？
其他可能原因
全表扫描：大表无索引查询。
排序/临时表：ORDER BY、GROUP BY 未用索引，检查 Created_tmp_tables。
复制问题：主从延迟导致从库堆积查询。
Bug 或优化器缺陷：特定版本已知问题（检查 MySQL 官方 Bug 列表）。

ALTER TABLE orders ADD INDEX idx_customer_status (customer_id, status); -- 复合索引ALTER TABLE logs DROP INDEX unused_idx; -- 删除冗余索引

# my.cnf 调整示例 innodb_buffer_pool_size = 系统内存的70%-80% max_connections = 500 # 根据实际需求调整thread_cache_size = 50 # 减少线程创建开销

修改配置后需重启 MySQL 或动态设置（如 SET GLOBAL max_connections=500;）。