MySQL 8.0 升到 8.4 后变慢实测：写入慢 2.3–3.4 倍，主因是 change buffer 默认关了，不是自适应哈希

两个实例的 my.cnf 只写了端口、路径、关闭 binlog 和缓冲池大小，其余全用编译默认值。我导出两边全部 innodb_% 和 temptable_% 变量做 diff，得到下面 13 项（不含版本号）。官方《What Is New in MySQL 8.4 since MySQL 8.0》的 Table 1.1 列出的也是这一批，另外几项（buffer_pool_instances、page_cleaners、parallel_read_threads 等）在本机配置下两边取值相同或只是计算方式变化。

判断一项变化会不会让你变慢，先看它影响的是哪条路径：change_buffering 影响写二级索引时要不要先读页；adaptive_hash_index 影响读路径上 B 树查找；flush_method、io_capacity、doublewrite 影响刷盘。下面两节就按这个顺序测。

测试负载：orders 表有主键和两个二级索引，idx_order_no(order_no=MD5(id)) 和 idx_shop_status(shop_id, status)，键值随机分布。每一轮都先把 orders 重置成同一份 300 万行、慢关机合并干净，再用 128MB 缓冲池冷启动，然后用存储过程分 200 批、每批 1000 行插入 20 万新行。128MB 远小于约 300MB 的二级索引，模拟「索引装不进内存的写多表」。

change buffer 的作用是：要改的二级索引页不在缓冲池时，先把改动记下来，等这个页以后被读进来时再合并，从而省掉一次随机读。8.4 默认 none 之后，每插一行都要先把对应的 idx_order_no 页从磁盘读进来。这一轮读盘页数从约 5 千涨到约 20.7 万，读了 3.2GB，耗时也跟着翻了 2–3 倍。

网上很多文章把 8.4 变慢归到 AHI 关闭。我在 8.4.10、1GB 缓冲池（数据全在内存）下用 mysqlslap 动态开关 innodb_adaptive_hash_index 测了三类读：随机点查、3 万行热点点查、10 万行热点 id 去 join orders（每个客户端跑 10 次）。每组 3 次，先预热再计时。

结论很清楚：点查和单线程 join 开关无差别，差值在噪声范围内；只有 8 并发 join 时，关闭 AHI 要 6.27–6.39 秒，开启只要 4.83–4.97 秒，慢约 28%。从 innodb_metrics 看，开启后 8 并发这一组约 1,000 万次查找走了哈希（adaptive_hash_searches），关闭时这些全部回到 B 树查找（adaptive_hash_searches_btree 约 1,560 万）。

这次我考虑过五个切入角度：把 13 项默认值做成升级清单；AHI 该不该打开；加内存比改参数更有效；别把 8.0 的 my.cnf 原样抄回去；以及「升级后写入变慢，主因是 change buffer」。最后我选了最后一个作为主判断，因为它最能直接指导排查顺序，而且有一个干净的对照（8.0 上单独关掉 change buffer 就复现了变慢）。

理由有三。第一，影响量级不同：写入路径慢 2.3–3.4 倍，AHI 只在特定读负载上差约 28%。第二，症状可以直接量出来：change buffer 关闭导致的变慢一定伴随 Innodb_buffer_pool_reads 暴涨，看一个计数器就能确认或排除，不用猜。第三，修法不止一种：如果内存允许，让二级索引装进缓冲池（本次 1GB 时 3.14–3.32 秒）比改回 change buffering 更稳，也避开了后台合并带来的额外 IO。

我不建议「把 8.0 的整份默认值抄回 8.4」。flush_method 改回 fsync 本次没有任何收益，io_capacity 该设多少取决于磁盘的真实 IOPS——这几项要各自按证据决定，而不是一次性回退。

下面这些都是只读查询，下载区的 SQL 文件里有完整版本。最好在升级前的 8.0 上先跑一遍留底，升级后同一时段再跑一遍对比；没有留底的话，就用业务低峰和高峰各取一次。