MySQL 5.7升级MySQL 8.0后性能下降如何排查？

MySQL 8.0性能下降主因是旧配置+新默认行为+优化器更严格三者叠加暴露历史隐患，须从执行计划、持久化配置、隐式转换切入：统计信息过期需ANALYZE TABLE WITH SYNC修复；sort_buffer_size不足引发filesort需调优并建复合索引；PERSIST配置优先级高于my.cnf需核查生效源；隐式类型转换在STRICT模式下导致索引失效，应统一字段与参数类型或建虚拟列索引。

性能下降不是 MySQL 8.0 变慢了，而是旧配置 + 新默认行为 + 优化器更“较真”三者叠加暴露了历史隐患——必须从执行计划、持久化配置、隐式转换三个入口直接切入。

EXPLAIN 显示 rows 暴涨或 type 退化为 ALL 怎么办

这是最明确的信号：优化器误判索引选择性，根源是 INNODB_TABLESTATS.last_update 还卡在升级前。

1. 查统计更新时间：SELECT last_update FROM INFORMATION_SCHEMA.INNODB_TABLESTATS WHERE TABLE_NAME = 'your_table'，若早于升级时间，立刻失效
2. 别等 innodb_stats_auto_recalc=ON ——它只对单次变更超 10% 行数的表触发，冷表/配置表永远不动
3. 执行 ANALYZE TABLE your_table WITH SYNC，加 WITH SYNC 避免后台异步延迟
4. 验证基数是否失真：SHOW INDEX FROM your_table 中的 Cardinality 值，对比 SELECT COUNT(DISTINCT your_col) FROM your_table，差 10 倍以上就确认失效

sort_buffer_size 不够导致 Using filesort 突然变多

MySQL 8.0.20+ 彻底废弃 max_length_for_sort_data，改用全字段内存排序模型，sort_buffer_size 不够就立刻写磁盘临时文件。

1. 检查 EXPLAIN 输出中 Extra 列是否含 Using filesort；不含才算真正走索引排序
2. 临时修复：给 WHERE + ORDER BY 字段建复合索引，例如 WHERE a=1 ORDER BY b,c 就建 INDEX(a,b,c)
3. 避免 SELECT * 加剧恶化——字段越多，filesort 内存压力越大；先试 SELECT a,b,c 看是否恢复毫秒级
4. sort_buffer_size 是 per-connection 分配的，设太大易引发内存爆炸；建议从 512K 起调，结合 EXPLAIN ANALYZE 观察实际排序内存使用

SET PERSIST 写入的配置覆盖了 my.cnf

MySQL 8.0 的 PERSIST 机制会把变量写入 mysqld-auto.cnf，该文件优先级高于 my.cnf，容易让配置“看似修改实则无效”。

1. 查当前生效值：SELECT * FROM performance_schema.persisted_variables
2. 查加载顺序：SELECT VARIABLE_NAME, VARIABLE_SOURCE, VARIABLE_PATH FROM performance_schema.variables_info WHERE VARIABLE_SOURCE IN ('PERSISTED', 'CONFIG')
3. 若发现关键变量（如 sort_buffer_size）来源是 PERSISTED，但你只改了 my.cnf，那配置根本没生效
4. 临时清空（慎用）：RESET PERSIST，再重启验证

WHERE 条件里字符串和 INT 字段比较突然变慢

MySQL 8.0 默认开启 STRICT_TRANS_TABLES，不再容忍隐式类型转换，优化器直接放弃索引路径，type 退化为 ALL。

1. 验证方式：SELECT @@sql_mode 确认是否含 STRICT_TRANS_TABLES；再查 SHOW CREATE TABLE 确认字段类型与传参是否严格匹配
2. 典型现象：WHERE user_id = '123'（user_id 是 INT）在 5.7 能走索引，8.0 直接全表扫
3. JSON 字段更危险：WHERE JSON_CONTAINS(meta, '"admin"') 若 JSON 内存的是数字 123 或无引号字符串 admin，不匹配就全表解析每个 blob
4. 根治办法：建 STORED 虚拟列并索引，例如 role_flag TINYINT AS (JSON_CONTAINS(meta, '"admin"')) STORED，再查 WHERE role_flag = 1

真正容易被忽略的点是：MySQL 8.0 的“默认行为”不是静态快照，而是动态适配结果——比如 innodb_buffer_pool_size 在 8.0 下有 15%~20% 被元数据悄悄占掉，performance_schema.data_locks 表记录所有事务锁而非仅阻塞锁，一不留神就拖垮全局互斥量。问题不在版本，而在你是否看清了这些变化如何真实作用于你的数据和查询。