MySQL 5.7升8.0后ORDER BY变慢主因是优化器默认启用derived_merge和hash_join，并改用激进filesort策略；JSON_CONTAINS变慢因UTF8MB4校验加重且需虚拟列索引；GROUP BY报错源于ONLY_FULL_GROUP_BY严格模式；IN子查询变慢因半连接优化退化。
MySQL 5.7 升级到 8.0 后 ORDER BY 变慢的典型表现
升级后某些带 ORDER BY 的查询响应时间翻倍，尤其是涉及多列排序、JSON 字段或隐式类型转换的场景。这不是偶发问题，而是优化器行为变更导致的确定性退化。
根本原因是 MySQL 8.0 默认启用 optimizer_switch='derived_merge=on,hash_join=on'，同时重写了排序算法路径：不再优先走覆盖索引的有序扫描，转而依赖更激进的内存排序（filesort）策略。如果 sort_buffer_size 不足或字段长度大，就会触发磁盘临时文件，性能断崖下跌。
- 检查是否命中索引排序：执行
EXPLAIN看Extra列是否含Using filesort - 临时修复：在 SQL 开头加
/*+ USE_INDEX(@sel_1 tbl_name (idx_col)) */强制走有序索引 - 长期方案：对排序字段补全复合索引，例如原查
WHERE a=1 ORDER BY b,c，建INDEX(a,b,c)
MySQL 8.0 的 JSON_CONTAINS 查询比 5.7 慢 3–5 倍的原因
8.0 对 JSON 字段引入了更严格的 UTF8MB4 校验和解析路径，JSON_CONTAINS 在无索引支持时会全表解析每个 JSON blob，开销远超 5.7 的轻量级匹配逻辑。
关键限制是：即使你在 JSON 字段上建了虚拟列 + 索引，也必须显式使用该虚拟列才能走索引。直接在原 JSON 字段上调用 JSON_CONTAINS 仍会全表扫。
- 错误写法：
WHERE JSON_CONTAINS(meta, '"admin"', '$.roles')→ 全表解析 - 正确写法：先建虚拟列
role_admin TINYINT AS (JSON_CONTAINS(meta, '"admin"', '$.roles')) STORED，再查WHERE role_admin = 1 - 注意：虚拟列必须设为
STORED才能被索引；VIRTUAL列无法建索引
从 5.6 升级到 5.7 时 GROUP BY 报错 ERROR 1055 的实质
这不是性能问题，但直接影响查询能否执行——5.7 默认开启 sql_mode='ONLY_FULL_GROUP_BY'，要求 SELECT 列必须全部出现在 GROUP BY 子句中，或为聚合函数结果。很多旧业务的“松散 GROUP BY”写法会直接失败。
表面是语法报错，深层影响性能：关闭该模式虽能兼容，但会让优化器放弃对 GROUP BY 的物化优化，改用更慢的临时表 + 文件排序路径，尤其在大数据量下延迟明显升高。
- 不推荐永久关闭：
SET GLOBAL sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY','')) - 推荐重构：用
ANY_VALUE()显式声明非分组列的取值逻辑，例如SELECT ANY_VALUE(name), COUNT(*) FROM t GROUP BY dept - 验证影响：对比
EXPLAIN FORMAT=TREE输出，看是否有Using temporary; Using filesort
升级后 IN 子查询突然变慢，且 EXPLAIN 显示 select_type=DEPENDENT SUBQUERY
这是 MySQL 5.7+ 对子查询去关联化的默认策略收紧所致。旧版本常把 IN (SELECT ...) 自动转成半连接（semijoin），而新版本在某些条件下（如子查询含 LIMIT、ORDER BY 或外部引用过多）会退化为逐行驱动的关联执行，复杂度从 O(N) 变成 O(N×M)。
一个常被忽略的触发点是子查询里用了用户变量（@var）或 UUID() 这类非确定性函数，这会直接禁用所有子查询优化路径。
- 快速验证：把子查询单独执行，看是否返回少量结果；若结果集 > 1000 行，
IN效率必然暴跌 - 替换方案：改用
JOIN或EXISTS，例如WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.id = t1.ref_id) - 紧急绕过：加提示
/*+ NO_SEMIJOIN(@subq1) */强制走传统嵌套循环
版本升级带来的性能变化，往往藏在那些“没报错、只变慢”的查询里。最危险的是优化器自动选错执行计划——它不会警告你，只会默默拖慢接口。上线前务必用生产数据集跑一遍慢日志里的高频查询，别只盯着 DDL 和启动项。
