mysql 8.0升级后sql变慢主因是优化器“重新认识数据”：统计信息陈旧（last_update滞后）、optimizer_switch默认启用hash_join/skip_scan等新特性导致误判、cost_model对排序更敏感引发filesort/temporary；需对比explain的type/rows/extra变化，及时analyze table并按需更新直方图。
不是所有SQL都变慢，但变慢的几乎都和优化器“重新认识数据”有关——统计信息没更新、optimizer_switch默认值变了、cost_model开始较真了。
查执行计划是否突变（重点看rows和type）
升级前后同一条SQL跑EXPLAIN，对比关键字段：
-
type从ref变成ALL：大概率索引被跳过，不是SQL写错了，是优化器误判选择性 -
rows预估暴涨几倍甚至几十倍：说明INNODB_TABLESTATS.last_update时间还卡在升级前，统计信息失效 -
Extra里突然出现Using filesort或Using temporary：ORDER BY或GROUP BY没走索引排序，8.0的cost_model更倾向全量读再排 - 用
EXPLAIN FORMAT=TREE搜using_index_merge：如果看到这个，说明8.0.19+自动合并了你本想禁用的单列索引
确认统计信息是否陈旧（别等自动更新）
8.0默认开启innodb_stats_auto_recalc=ON，但它只对“单次变更超10%行数”的表触发——冷表、配置表、历史归档表永远不动。
- 查
last_update：SELECT last_update FROM INFORMATION_SCHEMA.INNODB_TABLESTATS WHERE TABLE_NAME = 'your_table'，若早于升级时间，就是它 - 比
Cardinality：SHOW INDEX FROM your_table里的值，和SELECT COUNT(DISTINCT col) FROM your_table差10倍以上，基本失真 - 别加
PERSISTENT FOR ALL：ANALYZE TABLE your_table就行，加这个语法在8.0报错 - 大表怕锁：加
WITH SYNC强制同步更新，避免后台异步延迟：ANALYZE TABLE t1 WITH SYNC
检查optimizer_switch和排序行为变化
8.0默认启用hash_join=on、skip_scan=on、index_merge=on，看着是增强，但容易在小表JOIN大表、低基数字段或NULL值多时劣化。
- 查当前开关：
SELECT @@optimizer_switch\G - 临时验证：关掉可疑项，比如
SET SESSION optimizer_switch='hash_join=off,skip_scan=off'; -
max_length_for_sort_data在8.0.20+已废弃：原来靠它控制“用row_id还是全字段排序”，现在一律按实际字段长度算内存开销，SELECT *+ORDER BY极易触发磁盘filesort - ORDER BY没索引时，别只试
SELECT a,b,c——先补联合索引，比如WHERE a=1 ORDER BY b,c就建INDEX(a,b,c)
留意系统视图和监控SQL的隐性兼容问题
有些慢不是业务SQL引起的，而是监控脚本本身在8.0里变重了。
-
sys.innodb_lock_waits在8.0底层改用performance_schema.data_lock_waits，JOIN逻辑更重，高并发下可能阻塞业务SQL - 检查慢日志里是否高频出现
SELECT * FROM sys.innodb_lock_waits这类语句 - 类似地，
INFORMATION_SCHEMA里某些表（如INNODB_TRX）在8.0查询成本更高，监控脚本需重写或加缓存 - 慢日志“变少”不等于变快：8.0默认只记录已提交事务的慢语句，未提交的被过滤了——别被假象骗过
最常被忽略的是：统计信息更新后，cost_model仍可能低估排序成本，除非补直方图。对高倾斜字段（如状态码、时间分区），得手动跑ANALYZE TABLE tbl UPDATE HISTOGRAM ON col，否则优化器还是“看不见”数据分布。
