1. 诊断前的基线与目标设定
1.1 基线的重要性
建立基线是排查 MySQL CPU 占用过高的第一步。通过将当前系统在不同工作负载下的CPU利用率、查询吞吐量和响应时间与历史数据对比，能够快速识别异常波动和趋势变化的区间。明确可接受的峰值，有助于后续的容量规划与变更评估。
在实际场景中，常用的基线指标包括CPU平均利用率、TPS/QPS、慢查询比例以及并发连接数。将这些指标随时间绘制成图表，可以直观看到在高峰期CPU是否超出正常范围。将基线设定与业务峰值对齐，避免过度优化造成资源浪费。
1.2 收集历史数据和工作负载信息
为了快速定位问题源，需收集历史CPU曲线、慢查询日志和工作负载时间表。在高峰时段外，记录一次完整的基线快照，作为对照。工作负载的季节性规律也应被纳入考量，以免误把周期性波动误判为瓶颈。
常用做法是组合使用系统监控和数据库监控：系统层面的CPU、内存、磁盘I/O，以及数据库层面的查询耗时、锁等待、活跃连接等。下面给出一个参考命令，用于初步评估CPU压力趋势：以过去1小时为区间的CPU统计。
# 查看过去1小时内的CPU利用率分布（Linux 命令示例）
sar -u 60 60
2. 瓶颈定位工具与指标
2.1 常用监控工具
要实现从性能瓶颈诊断到实际优化的全流程，需要一组可视化且可追溯的监控工具。对于 MySQL，常见的有性能模式 Performance Schema、InnoDB 监控、以及外部监控平台（如 PMM、Prometheus+Grafana）等。性能模式的汇总表可以帮助你快速识别高消耗的查询和资源等待。
在具体落地时，建议启用 Performance Schema 的摘要视图，以及 InnoDB 存储引擎自带的监控表，结合外部图表呈现，便于对比不同时间段的指标变化。下面展示一个在 Performance Schema 中定位高耗时查询的示例：
SELECT DIGEST_TEXT, SUM_TIMER_WAIT/1000000000000 AS total_seconds, COUNT_STAR AS execs
FROM performance_schema.events_statements_summary_by_digest
ORDER BY total_seconds DESC
LIMIT 10;
2.2 关键CPU指标含义
在排查过程中，关注以下核心指标有助于快速定位问题根源：CPU利用率分布、单次查询的CPU时间占比、活跃线程数、锁等待时间、以及 上下文切换和磁盘I/O 等待。通过对比慢查询的占比与总吞吐量，可以区分是 SQL 层面的问题还是系统资源瓶颈。
要点总结：高CPU且慢查询占比高，往往指向查询缺乏优化；高CPU但慢查询占比低，可能是并发引起的锁、IO 或连接管理问题。结合性能_schema 的 digest 统计和 SHOW PROCESSLIST，可以把注意力聚焦在最耗时的语句上。
3. 常见CPU高的原因及诊断步骤
3.1 问题类型：慢查询、锁、IO等
MySQL CPU 高的常见原因大致可以归类为：慢查询未优化、高并发下的锁等待、磁盘 I/O 瓶颈、以及 无效的索引或查询模式。在诊断时，先用顶部级别的指标筛选出可能的区域，再逐步深入具体语句或表的层面。需要特别关注慢查询日志、锁等待信息和 磁盘吞吐 的变化。
若出现大量并发连接且CPU持续飙高，应首先排查连接池配置与应用端的并发模型；若出现慢查询比例明显提高，则应重点分析查询语句、索引结构与执行计划，必要时对查询进行改写或重写。
4. 针对性优化策略
4.1 SQL层优化
SQL 层面的优化通常能快速降低 CPU 占用。优先级高的措施包括：使用正确的索引、避免全表扫描、尽量减少大文本字段的处理、以及通过 EXPLAIN 评估查询计划。对于经常执行的慢查询，优先进行查询改写或结构化索引设计。
下面给出一个示例，展示如何通过 EXPLAIN 评估一个查询并进行优化方向判定：分析执行计划，找出全表扫描和索引覆盖情况。
EXPLAIN SELECT o.id, o.total, u.status
FROM orders AS o
JOIN users AS u ON o.user_id = u.id
WHERE o.created_at >= '2025-01-01'AND u.active = 1
ORDER BY o.created_at DESC
LIMIT 100;
在分析结果中，若发现使用了不覆盖的索引或出现了Using filesort、Using temporary等代价高的操作，就需要考虑添加覆盖索引、调整查询条件顺序、或将大查询拆分成更小的块执行。
4.2 配置参数优化
合理的数据库配置对降低CPU压力至关重要。核心思路是让内存、并发、I/O 等资源的分配符合实际工作负载。增大 InnoDB 缓冲池、合理设置并发 I/O、以及避免过多的连接上下文切换，通常能显著降低 CPU 占用。
示例设置（以常见的 MySQL 服务器为例，数值需结合实际内存与工作负载做调整）：
SET GLOBAL innodb_buffer_pool_size = 2 * 1024 * 1024 * 1024; -- 2G，实际应根据机器内存调整
SET GLOBAL max_connections = 600;
SET GLOBAL innodb_read_io_threads = 4;
SET GLOBAL innodb_write_io_threads = 4;
请注意，某些参数的调整需要重启生效或对线上环境进行容量评估后再执行，以避免对服务可用性造成影响。进一步的优化还包括移除过期的日志文件、开启适当的慢查询日志等级，以及根据 workload 调整日志缓冲行为。
4.3 索引与查询重写
索引的正确性直接决定查询性能和 CPU 占用。应优先创建必要的、覆盖查询所需的最小索引结构，并避免冗余索引带来的额外写负载。对复杂查询，考虑通过将多列条件放在前置筛选、使用子查询分解、以及适时的分区策略来提升效率。
示例：为经常按用户和创建时间筛选的查询创建覆盖索引；同时，避免在 where 子句使用函数对字段进行处理，这会阻止索引的使用。创建索引的示例：
CREATE INDEX idx_orders_user_created ON orders(user_id, created_at DESC);
完成索引后，重新执行 Explain，确认查询计划中使用了索引覆盖且避免了 Using temporary/Using filesort。如果需要，可以进一步拆分大查询或改写为更小的子查询，以实现更好的并发和 CPU 利用。
5. 变更验证与回滚
5.1 验证指标回归
完成优化变更后，应对关键指标进行回归验证，确保CPU 占用趋势转好、慢查询响应时间下降、吞吐量维持或提升。对比优化前后的同一时间段数据，关注CPU 峰值、平均延迟、TPS以及慢查询比例等。
常用验证步骤包括重新采集系统层面的 CPU、内存、I/O 指标，以及数据库层面的慢查询、锁等待等信息。若观察到负面影响，应考虑回滚变更并回到基线状态。
SHOW GLOBAL STATUS LIKE 'Questions';
SHOW GLOBAL STATUS LIKE 'Slow_queries';
SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool_size';
5.2 回滚与逐步发布
在生产环境中，逐步发布与灰度验证是降低风险的关键。若新策略导致异常CPU抬升，应迅速回滚，并在非高峰时段完成进一步的对比测试。回滚操作要有文档化的步骤和监控清单，以确保可追溯性。
按计划的回滚流程能够帮助团队快速恢复服务，同时保留对问题根因的可追踪性，便于后续的精细化调优和容量规划。
