MySQL 8.0查询未必更快，需通过EXPLAIN FORMAT=TREE验证执行计划是否真正优化，结合相同配置、关闭query cache、对比type/rows/filtered及SYS schema分析，否则表面“变快”实为假象。
MySQL 8.0 vs 5.7：先看查询执行计划是否真变快了
单纯升级到 MySQL 8.0 不等于查询变快，很多用户发现 EXPLAIN 输出看起来更“漂亮”，但实际响应时间没变化甚至更慢。关键要看 EXPLAIN FORMAT=TREE（8.0 新增）是否揭示了更优的连接顺序或物化优化，而 5.7 只能用传统 EXPLAIN 看不到这些细节。
- 对比时务必在相同数据量、相同 buffer 配置（如
innodb_buffer_pool_size）、关闭 query cache（5.7 默认开，8.0 已移除）下运行 - 特别注意
type字段：8.0 中ref_or_null或index_merge的实际开销可能比 5.7 的range更高，需结合rows和filtered综合判断 - 用
SYS schema（8.0 自带）查statement_analysis，比 5.7 手动解析 slow log 更准：它会自动归一化 SQL 并统计平均延迟、全表扫描次数
事务与锁行为差异直接影响并发吞吐
MySQL 8.0 默认启用 innodb_read_only 元数据锁优化和更激进的行锁释放策略，但某些场景下反而导致锁等待上升——尤其是大量短事务更新同一主键范围时。
- 5.7 的
SELECT ... FOR UPDATE在非唯一索引上可能升级为间隙锁（gap lock），8.0 在READ-COMMITTED下默认不加 gap lock，但若应用依赖该行为做并发控制，会出现幻读 -
innodb_autoinc_lock_mode=2（8.0 默认）提升插入并发，但会导致自增 ID 不连续；若业务用 ID 做分页或幂等校验，需提前确认兼容性 - 检查
INFORMATION_SCHEMA.INNODB_TRX中的trx_wait_started和trx_weight，8.0 新增字段能更快定位锁争用源头
JSON 和窗口函数不是性能加速器，而是新瓶颈点
8.0 引入 JSON_CONTAINS、ROW_NUMBER() 等能力，但它们默认不走索引，且计算开销远高于等值查询。很多用户把 JSON 字段当普通列用，结果全表扫描+CPU 解析成为新瓶颈。
-
JSON_EXTRACT(json_col, '$.field')无法直接使用普通 B-tree 索引；必须建函数索引：CREATE INDEX idx_json_field ON t1 ((JSON_EXTRACT(json_col, '$.field'))) - 窗口函数如
RANK() OVER (PARTITION BY x ORDER BY y)在大数据集上内存消耗陡增，sort_buffer_size不足时会写磁盘临时文件，反而比 5.7 的子查询+JOIN 更慢 - 用
performance_schema.events_statements_summary_by_digest查看 JSON 相关语句的avg_timer_wait，若显著高于其他语句，基本可判定是解析开销问题
升级后性能下降？先盯住 redo log 和 doublewrite buffer
MySQL 8.0 默认开启 innodb_dedicated_server，会自动调大 innodb_log_file_size 和 innodb_doublewrite 配置，但在小内存或 SSD 性能一般的机器上，反而造成写放大和 checkpoint 延迟。
- 如果观察到
Innodb_os_log_written暴涨但Innodb_buffer_pool_pages_dirty长期高位，说明 redo log 写入压力过大，建议手动设回innodb_log_file_size = 256M（5.7 常用值） - 8.0 默认启用
innodb_doublewrite=ON（5.7 是MODE=2即只对 page size ≠ 16KB 启用），若磁盘 IOPS 有限，可改用innodb_doublewrite=OFF（仅限有 RAID 或副本保障的环境） - 用
SHOW ENGINE INNODB STATUS\G查看LOGsection 中的Log sequence number和Last checkpoint at差值，超过 1GB 就需警惕刷脏滞后
真实压测中，最常被忽略的是字符集与排序规则变更：8.0 默认 utf8mb4_0900_as_cs 比 5.7 的 utf8mb4_general_ci 排序更精确但更慢，尤其在 ORDER BY + LIMIT 场景下，索引覆盖失效风险更高。别只盯着版本号，先跑一遍 SELECT * FROM t ORDER BY c LIMIT 10 的 EXPLAIN 对比。
