MySQL 5.7 在高水位线下性能优于 8.0——因 5.7 的 redo 写入路径更轻量，而 8.0 默认的 CRC 校验、page hash 锁竞争、performance_schema 全采集等在高压力下放大延迟抖动。
为什么“高水位线”下 5.7 反而更优？
所谓“高水位线”，通常指 buffer pool 使用率长期 >85%、redo log 持续接近 checkpoint_lsn 上限、或脏页比例频繁触达 innodb_max_dirty_pages_pct 阈值的状态。这种压力下，5.7 的旧路径反而更轻量：
- 5.7 的 redo 写入路径更直接：log buffer → os cache → fsync，中间环节少，锁粒度粗但稳定
- 8.0 在 5.7 基础上增加了 CRC 校验、page hash chain 锁竞争、以及与
caching_sha2_password握手阶段的隐式系统调用耦合——这些在高水位时会放大延迟抖动 - 8.0 默认开启
performance_schema全采集（尤其在 8.0.22+），而高水位常伴随 CPU 缓存失效加剧，P_S 的 instrumentation 开销会吃掉 5%~10% 的有效吞吐
哪些配置会让 8.0 在高水位下“雪上加霜”？
如果你观察到 8.0 在高水位时 TPS 断崖下跌，大概率不是引擎本身问题，而是默认行为被误用：
-
innodb_redo_log_encrypt=OFF是默认值，但 8.0 的未加密 redo 日志仍强制走 CRC + buffer chain lock，小事务密集写入时易成瓶颈 -
binlog_order_commits=ON（默认）让 binlog prepare 与 InnoDB prepare 强耦合，在高并发提交下，事务排队等待时间呈非线性增长 -
information_schema_stats_expiry=3600（默认开启）导致统计信息缓存常驻 buffer pool，实测可悄悄吃掉 15%~20% 的innodb_buffer_pool_size - 没执行
ANALYZE TABLE就跑复杂查询，8.0 的 Cost Model 会基于过期统计瞎估，生成低效执行计划，进一步推高 buffer pool 压力
如何公平对比高水位下的真实能力？
直接改配置不解决问题，关键是让测试反映真实约束：
- 每次测试前必须重置并验证：
SET GLOBAL innodb_max_dirty_pages_pct = 90（8.0 默认）、SET GLOBAL innodb_flush_neighbors = 0（SSD 必设） - 清空 OS cache：
echo 3 | sudo tee /proc/sys/vm/drop_caches，且必须重启 mysqld（仅FLUSH TABLES不够） - 建表后立刻执行
ANALYZE TABLE sbtest1，否则 8.0 的执行计划极易失真 - 禁用干扰项：
SET GLOBAL performance_schema = OFF（测试期间），避免 instrumentation 混淆 IO/CPU 瓶颈判断
