1. MySQL高CPU使用率问题全景分析当数据库服务器的CPU使用率持续超过80%时整个系统的响应速度就会明显下降严重时甚至会导致服务不可用。作为关系型数据库的典型代表MySQL在高并发场景下经常成为CPU资源的消耗大户。不同于内存或磁盘问题通常有明显的错误日志CPU使用率过高往往需要DBA主动出击进行排查。我处理过最典型的案例是一个电商平台的MySQL实例在促销活动期间CPU长期保持在95%以上导致订单提交延迟高达15秒。通过下文介绍的排查方法最终发现是未优化的商品分类查询引发了全表扫描。这个案例让我深刻认识到——CPU使用率就像数据库的体温计异常升高往往预示着更深层次的疾病。2. 核心排查工具与诊断流程2.1 操作系统层面监控首先通过top命令确认CPU消耗确实来自mysqld进程top - 11:30:45 up 2 days, 3 users, load average: 4.25, 3.18, 2.75 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND 1121 mysql 20 0 25.4g 4.2g 3.8g S 187.3 13.6 45:20.12 mysqld关键指标解读%CPU 100%表示进程使用了多个核心配合vmstat 1查看系统整体CPU的us(用户态)/sy(内核态)占比pidstat -p 1121 1可细化到线程级别的CPU占用2.2 MySQL内置诊断工具2.2.1 活跃会话分析SELECT * FROM information_schema.processlist WHERE COMMAND ! Sleep ORDER BY TIME DESC LIMIT 10;重点关注TIME 60秒的长查询STATE为Sending data、Copying to tmp table等INFO字段显示的具体SQL语句2.2.2 性能模式(Performance Schema)-- 开启所有监控项 UPDATE performance_schema.setup_instruments SET ENABLED YES; -- 查看最高CPU消耗的SQL SELECT digest_text, sum_timer_wait/1000000000 AS latency_sec, sum_created_tmp_tables, sum_sort_merge_passes FROM performance_schema.events_statements_summary_by_digest ORDER BY sum_timer_wait DESC LIMIT 5;3. 六大常见原因深度解析3.1 低效SQL查询全表扫描是最典型的CPU杀手通过EXPLAIN识别EXPLAIN SELECT * FROM orders WHERE create_time 2023-01-01;关键危险信号typeALL全表扫描rows预估扫描行数极大Extra中出现Using filesort、Using temporary优化方案为WHERE条件字段添加索引重写SQL避免SELECT *对大数据量表使用分区策略3.2 锁竞争激烈通过以下命令检测锁等待SELECT * FROM sys.innodb_lock_waits;典型场景热点行更新如计数器长事务持有锁时间过长不合理的隔离级别设置解决方案-- 临时方案终止阻塞事务 KILL [processlist_id]; -- 长期方案优化事务逻辑 SET GLOBAL innodb_lock_wait_timeout 30; -- 默认50秒降为30秒3.3 配置参数不当关键参数检查清单参数名推荐值错误配置的影响innodb_buffer_pool_size物理内存的70-80%过小导致频繁磁盘IOtable_open_cache4000表缓存频繁重建tmp_table_size64M临时表磁盘化调整方法-- 动态修改需同时更新my.cnf SET GLOBAL innodb_buffer_pool_size12G;3.4 连接风暴突发大量连接会导致CPU忙于线程创建SHOW STATUS LIKE Threads_connected; SHOW VARIABLES LIKE max_connections;应急处理# 快速限制新连接 mysqladmin -uroot -p flush-hosts长期方案配置连接池建议HikariCP设置合理的wait_timeout部署读写分离架构3.5 复制问题主从复制异常会导致SQL线程高CPUSHOW SLAVE STATUS\G重点关注Seconds_Behind_Master持续增长Slave_SQL_Running_State显示Applying batchLast_Error字段报错信息修复步骤停止复制STOP SLAVE;跳过错误SET GLOBAL sql_slave_skip_counter1;重启复制START SLAVE;3.6 硬件资源不足当QPS增长超过服务器处理能力时CPU使用率自然上升。通过基准测试确认sysbench oltp_read_write --db-drivermysql --mysql-host127.0.0.1 \ --mysql-usertest --mysql-passwordtest --mysql-dbsbtest \ --tables10 --table-size100000 --threads32 --time300 run扩容建议CPU密集型负载升级至更高主频的CPUIO密集型负载考虑改用NVMe SSD混合型负载建议分库分表4. 高级诊断技巧4.1 火焰图分析使用perf生成CPU火焰图perf record -p $(pidof mysqld) -g -- sleep 30 perf script | ./stackcollapse-perf.pl | ./flamegraph.pl mysql.svg分析要点平顶表示热点函数宽栈帧表示频繁调用路径关注JOIN::exec、handler::ha_index_read等关键函数4.2 慢查询日志深度分析配置示例my.cnfslow_query_log 1 slow_query_log_file /var/log/mysql/mysql-slow.log long_query_time 1 log_queries_not_using_indexes 1使用pt-query-digest分析pt-query-digest /var/log/mysql/mysql-slow.log slow_report.txt报告关键部分解读Rank问题SQL严重程度排序Response time占总时间的百分比Exec time单次执行耗时Rows examine扫描行数5. 预防性维护策略5.1 定期健康检查建议每周运行的SQL集合-- 索引使用统计 SELECT object_schema, object_name, index_name, count_read, count_fetch FROM performance_schema.table_io_waits_summary_by_index_usage ORDER BY count_read DESC; -- 缓冲池命中率 SELECT (1 - (SELECT variable_value FROM performance_schema.global_status WHERE variable_name Innodb_buffer_pool_reads) / (SELECT variable_value FROM performance_schema.global_status WHERE variable_name Innodb_buffer_pool_read_requests)) AS buffer_pool_hit_ratio;5.2 自动化监控告警推荐Prometheus监控指标mysql_global_status_questionsSQL执行频率mysql_global_status_threads_running并发线程数mysql_global_status_innodb_row_lock_time_avg平均锁等待时间Grafana报警阈值建议CPU使用率 70%持续5分钟活跃连接数 max_connections的80%缓冲池命中率 95%5.3 架构级优化方案当单实例优化达到瓶颈时应考虑读写分离使用ProxySQL实现自动路由分库分表推荐使用ShardingSphere缓存层Redis缓存热点数据异步处理将耗时操作移入消息队列6. 经典案例复盘某社交平台feed流服务CPU持续90%的解决过程现象每日晚高峰CPU飙升响应延迟2秒排查pt-query-digest发现TOP1 SQL占75%负载EXPLAIN显示该查询使用临时表文件排序优化添加复合索引(user_id, create_time)重写SQL移除ORDER BY RAND()效果CPU使用率降至40%P99延迟200ms关键教训不要在生产环境使用ORDER BY RAND()定期检查新上线SQL的执行计划压力测试应模拟真实业务场景