必须显式加ORDER BY才能公平对比：5.7隐式排序“碰巧”省去filesort，8.0默认无序可能额外触发filesort，且执行计划、统计信息、缓存机制等底层差异极大。
直接在两个版本上跑同一句 SELECT 看耗时，结果不可比——5.7 和 8.0 的执行路径、默认行为、优化器决策逻辑完全不同，不控制变量就测，等于拿苹果和橙子比甜度。
必须显式加 ORDER BY 才能公平对比 GROUP BY
MySQL 5.7 对 GROUP BY 隐式排序，8.0 默认不排序。如果你测的是 SELECT department, COUNT(*) FROM employees GROUP BY department，5.7 返回“看起来有序”的结果，8.0 可能完全乱序。这种差异会干扰后续逻辑（比如带 LIMIT 分页），更会导致 8.0 被迫补一次 Using filesort，而 5.7 “碰巧”省了。
- 所有对比测试必须显式加上
ORDER BY，例如：SELECT department, COUNT(*) FROM employees GROUP BY department ORDER BY department - 若只关心聚合本身（不依赖顺序），检查
EXPLAIN输出：8.0 中应无Using filesort；5.7 即使没写ORDER BY，Extra字段也常含该提示 - 8.0 用
EXPLAIN FORMAT=TREE可直观看到是否走Hash Aggregate；5.7 只能靠Extra推测是否用了临时表
EXPLAIN 输出不能直接跨版本对齐
5.7 和 8.0 的 EXPLAIN 结构、字段含义、甚至判断逻辑都变了。比如 type 为 index 在 5.7 可能表示全索引扫描，在 8.0 可能已启用降序索引跳过排序；key_len 计算方式也因 innodb_large_prefix 默认开启而不同。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 不要只看
type或rows数字是否变小，要结合Extra和实际执行计划节点（8.0 支持Hash Join、WindowAgg等新节点） - 5.7 没有
FORMAT=TREE，无法确认是否真正走哈希聚合；8.0 中若出现-> Hash Aggregate行，说明满足条件（非 LOB 列、仅基础聚合函数、内存足够） - 检查统计信息是否一致：8.0 默认启用直方图（
use_stat_tables = PREFERABLY），5.7 没这机制；未跑ANALYZE TABLE的 8.0 可能比 5.7 更保守
存储过程或含变量的 SQL 会彻底破坏可比性
同一段 SQL 在存储过程中执行，5.7 和 8.0 的执行计划缓存复用策略完全不同。8.0 对 DETERMINISTIC 校验更严，只要过程体里用了 @var、NOW()、RAND()，哪怕声明了 DETERMINISTIC，也会被标记为非确定性，导致每次调用都重新解析、生成执行计划。
- 排查方法：
SHOW CREATE PROCEDURE proc_name;看是否真写了DETERMINISTIC，再检查过程体内有没有隐式非确定操作 - 避免使用
@var传参，改用IN/OUT参数；时间类逻辑尽量用输入参数代替NOW() - 若 SQL 含用户变量（如
SELECT @a := @a + 1），直接放弃对比——8.0 不会缓存其执行计划，5.7 却可能误缓存
容易被忽略的底层差异点
很多性能波动其实来自元数据加载、事务隔离或缓冲池行为这些“看不见”的环节。比如 5.7 每次 EXPLAIN 都要打开 .frm 文件，8.0 全部走事务性数据字典缓存；又比如 8.0 默认 transaction_isolation = 'REPEATABLE-READ'，高并发下 SELECT ... FOR UPDATE 的 MVCC 开销远高于 5.7 常用的 READ-COMMITTED。
- 检查
information_schema_stats_expiry：8.0 默认 3600 秒，统计信息缓存久，但业务频繁 DDL 时可能误导优化器 - 确认
innodb_buffer_pool_instances是否合理设置（如设为 8），否则高并发下 buffer pool mutex 争用会抵消优势 - 复制场景下别只看主库耗时：8.0 的
WRITESET并行回放让从库延迟更低，但主库binlog_format=ROW+ 原子 DDL 会让单次DROP/CREATE PROCEDURE耗时暴涨 3–10 倍
