升级后响应变慢但慢查询日志无报错，首要检查Performance Schema是否启用（MySQL 5.7+默认禁用），并开启events_statements_%和events_waits_%等关键消费者，重点关注IO和锁等待事件飙升。
升级后响应变慢但慢查询日志没报错？先看 Performance Schema 是否启用
MySQL 5.7+ 默认禁用 performance_schema，而很多新版本的性能分析能力（如语句级等待、锁等待归因、内存分配统计）都依赖它。升级后若没手动开启，你看到的“一切正常”其实是“什么都没在监控”。
实操建议：
- 检查是否启用：
SELECT @@performance_schema;— 返回0就得马上开 - 重启前在
my.cnf加：performance_schema = ON（仅设为ON不够，还要确认相关消费者已启用） - 关键消费者必须开：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE 'events_statements_%' OR NAME LIKE 'events_waits_%'; - 别只查
events_statements_summary_by_digest，升级后常见问题是events_waits_summary_global_by_event_name里wait/io/file/innodb/innodb_data_file或wait/synch/mutex/innodb/buf_pool_mutex等待飙升 — 这说明底层并发模型或IO路径变了
EXPLAIN FORMAT=TREE 看不见嵌套循环？用新的执行计划格式补盲点
MySQL 8.0.16+ 引入 FORMAT=TREE，能清晰展示 JOIN 顺序、物化子查询、CTE 展开等旧版 EXPLAIN 隐藏的执行逻辑。升级后有些 SQL 表面 type=ref 很健康，实际却因物化代价高拖垮整体响应。
实操建议：
- 对升级后变慢的关键 SQL，强制用：
EXPLAIN FORMAT=TREE SELECT ... - 重点找
-> Materialize和-> Nested loop块 — 如果物化表行数远超预期，或嵌套层数 >3，大概率是优化器选了更“理论最优”但实际更慢的路径 - 对比升级前后
rows和filtered：8.0+ 的filtered更准，若从 95% 降到 5%，说明统计信息过期，立刻跑ANALYZE TABLE - 别信
key_len数值不变就等于索引没失效 — 新版本对函数索引、隐藏列、JSON 路径索引的key_len计算逻辑已不同
连接数暴增但 max_connections 没打满？查 thread_pool 和 SSL 握手开销
MySQL 8.0+ 默认启用 SSL，且线程复用策略变化较大。升级后常见现象是：应用端连接池配置没动，但 MySQL 侧 Threads_connected 持续高位，SHOW PROCESSLIST 里大量 SSL handshake 或 init 状态连接 — 实际不是业务并发高，而是连接建立成本翻倍。
实操建议：
- 确认是否启用了线程池插件：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE 'thread_pool%';，若启用但未调优，反而会加剧争用 - 检查 SSL 开销：
SHOW STATUS LIKE 'Ssl_%';中Ssl_accepts/Ssl_finished_accepts比值若长期 ssl_mode 配置 - 临时验证：在测试环境关 SSL（
ssl_mode=DISABLED）并重启应用连接池，观察Threads_created是否骤降 — 若下降明显，问题就在握手环节 - 避免盲目调大
max_connections：8.0+ 内存管理更细粒度，每个连接基础开销比 5.7 高约 15%，超配易触发 OOM Killer
缓冲池命中率跌到 90% 以下？别急着调 innodb_buffer_pool_size
升级后 Innodb_buffer_pool_hit_rate 下滑，第一反应调大 innodb_buffer_pool_size 是最危险的惯性操作。MySQL 8.0+ 的 Buffer Pool 管理机制变化（如 LRU 划分更细、预读策略激进），可能导致命中率统计失真，甚至调大后反而因频繁 page cleaner 压力引发 IO 尖刺。
实操建议：
- 先看真实压力源：
SELECT * FROM sys.innodb_buffer_pool_stats\G，重点关注pages_made_young和pages_not_made_young— 若后者占比突增，说明热点数据被冷数据挤出，根源是查询模式突变，不是内存不够 - 检查
innodb_old_blocks_pct：8.0 默认为 37（5.7 是 38），微小差异可能让老区数据过早淘汰，可尝试回设为 38 观察 - 用
iostat -x 1对比升级前后await和r_await：如果磁盘延迟没涨但命中率跌了，基本可排除物理 IO 问题，转向 SQL 分析 - 真正该调的是
innodb_buffer_pool_instances：8.0 推荐值 = min(64, buffer_pool_size_in_GB)，实例数太少会导致 mutex 争用，比盲目扩内存更有效
升级后的性能瓶颈往往藏在“看起来没变”的地方：统计信息陈旧、SSL 握手细节、线程生命周期、Buffer Pool 内部调度策略……这些不会报错，也不会进慢日志，但会让系统在高负载下突然失稳。盯住 performance_schema 里的等待事件，比盯着 SHOW PROCESSLIST 更管用。
