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 还卡在升级前。
- 查统计更新时间：
SELECT last_update FROM INFORMATION_SCHEMA.INNODB_TABLESTATS WHERE TABLE_NAME = 'your_table'，若早于升级时间，立刻失效 - 别等
innodb_stats_auto_recalc=ON——它只对单次变更超 10% 行数的表触发，冷表/配置表永远不动 - 执行
ANALYZE TABLE your_table WITH SYNC，加WITH SYNC避免后台异步延迟 - 验证基数是否失真：
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 不够就立刻写磁盘临时文件。
- 检查
EXPLAIN输出中Extra列是否含Using filesort；不含才算真正走索引排序 - 临时修复：给
WHERE + ORDER BY字段建复合索引，例如WHERE a=1 ORDER BY b,c就建INDEX(a,b,c) - 避免
SELECT *加剧恶化——字段越多，filesort 内存压力越大；先试SELECT a,b,c看是否恢复毫秒级 -
sort_buffer_size是 per-connection 分配的，设太大易引发内存爆炸；建议从512K起调，结合EXPLAIN ANALYZE观察实际排序内存使用
SET PERSIST 写入的配置覆盖了 my.cnf
MySQL 8.0 的 PERSIST 机制会把变量写入 mysqld-auto.cnf，该文件优先级高于 my.cnf，容易让配置“看似修改实则无效”。
- 查当前生效值：
SELECT * FROM performance_schema.persisted_variables - 查加载顺序：
SELECT VARIABLE_NAME, VARIABLE_SOURCE, VARIABLE_PATH FROM performance_schema.variables_info WHERE VARIABLE_SOURCE IN ('PERSISTED', 'CONFIG') - 若发现关键变量（如
sort_buffer_size）来源是PERSISTED，但你只改了my.cnf，那配置根本没生效 - 临时清空（慎用）：
RESET PERSIST，再重启验证
WHERE 条件里字符串和 INT 字段比较突然变慢
MySQL 8.0 默认开启 STRICT_TRANS_TABLES，不再容忍隐式类型转换，优化器直接放弃索引路径，type 退化为 ALL。
- 验证方式：
SELECT @@sql_mode确认是否含STRICT_TRANS_TABLES；再查SHOW CREATE TABLE确认字段类型与传参是否严格匹配 - 典型现象：
WHERE user_id = '123'（user_id是INT）在 5.7 能走索引，8.0 直接全表扫 - JSON 字段更危险：
WHERE JSON_CONTAINS(meta, '"admin"')若 JSON 内存的是数字123或无引号字符串admin，不匹配就全表解析每个 blob - 根治办法：建
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 表记录所有事务锁而非仅阻塞锁，一不留神就拖垮全局互斥量。问题不在版本，而在你是否看清了这些变化如何真实作用于你的数据和查询。
