MySQL升级后CPU升高主因是新版本激进的内存优化策略，如AHI和随机预读在局部性差时徒增CPU开销；可通过禁用AHI、关闭预读、检查执行计划、刷新统计信息及监控performance_schema定位根因。
MySQL 升级后 CPU 利用率不降反升，大概率不是 bug，而是新版本对索引结构（尤其是 InnoDB 的 B+Tree 内部节点分裂、自适应哈希索引（AHI）策略、缓冲池预读逻辑）做了更激进的内存优化——这些改动在高并发点查或范围扫描场景下，会显著增加 CPU 计算开销，而非降低。
确认是不是 AHI 或缓冲池预读引发的 CPU 激增
新版 MySQL（8.0.22+）默认启用更敏感的自适应哈希索引和更强的 innodb_random_read_ahead 行为。它们本意是加速重复访问，但若查询模式离散、缓存局部性差，反而导致大量无效哈希构建和预读丢弃，徒增 CPU 负担。
- 检查 AHI 是否活跃：
SHOW ENGINE INNODB STATUS\G，搜索hash searches/s和non-hash searches/s—— 若前者远低于后者（比如 1:10），说明 AHI 基本没起效，却仍在消耗 CPU 维护 - 临时禁用 AHI 验证影响：
SET GLOBAL innodb_adaptive_hash_index = OFF;（注意：该操作需重启才永久生效，但动态关闭可立即观察 CPU 变化） - 关掉随机预读：
SET GLOBAL innodb_random_read_ahead = OFF;，尤其当业务以小范围主键查询为主时，这个参数常是“CPU 杀手”
对比升级前后 EXPLAIN FORMAT=JSON 的索引访问路径差异
新版优化器可能改变了索引选择逻辑，比如原本走 ref 的等值查询，升级后因统计信息过期或代价模型调整，改走 range 甚至 index_merge，触发更多 CPU 密集型的行过滤或排序合并。
- 对典型慢查询执行：
EXPLAIN FORMAT=JSON SELECT ...，重点关注used_columns、range_analysis和rows_examined_per_scan - 若发现
key字段变了，或rows估算值大幅跳变（尤其变大），说明优化器“选错索引”了 - 强制指定旧版使用的索引测试：
SELECT ... FROM t USE INDEX (old_idx_name) WHERE ...，看 CPU 是否回落
重刷统计信息 + 锁定执行计划
升级后 INFORMATION_SCHEMA.STATISTICS 中的索引基数（CARDINALITY）可能未自动更新，导致优化器基于过时数据做决策；而新版又更依赖准确统计信息做 CPU 敏感型判断（如是否启用 MRR、是否下推条件）。
- 立刻刷新表统计：
ANALYZE TABLE your_table_name;（对大表加WITH SYNC确保同步完成） - 若某条查询在旧版稳定走某索引，新版反复漂移，用
CREATE OUTLINE（MySQL 8.0.23+）或SET optimizer_switch='use_index_extensions=off'临时锁定路径 - 避免盲目
OPTIMIZE TABLE—— 它会重建表并重算统计，但新版中可能触发更激进的页分裂，反而加剧 CPU 压力
监控 performance_schema 中的真实 CPU 消耗热点
别只看 top 里的 mysqld 进程总占用，要定位到具体函数级瓶颈。新版 performance_schema 提供了更细粒度的等待与阶段事件。
- 开启阶段监控：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE 'events_stages%'; - 查 CPU 最密集阶段：
SELECT EVENT_NAME, COUNT_STAR, SUM_TIMER_WAIT FROM performance_schema.events_stages_summary_global_by_event_name ORDER BY SUM_TIMER_WAIT DESC LIMIT 5;—— 若stage/innodb/row_lock_wait或stage/sql/Sorting result排前两位，说明锁或排序是根因，而非索引结构本身 - 特别关注
stage/innodb/insert_buffer_resize—— 升级后若innodb_change_buffer_max_size默认值被调高，且写入陡增，会导致后台合并线程频繁争抢 CPU
真正容易被忽略的是：新版 MySQL 对“冷数据”的内存管理更积极，但你的业务可能压根不需要它——比如 OLAP 类查询偶尔跑一次，却触发了全缓冲池扫描和哈希重建。这时候关掉 AHI 和预读，比调大 innodb_buffer_pool_size 更有效。
