SQL innodb_flush_neighbors 的邻页刷新策略在 SSD 时代禁用理由

ssd上必须设innodb_flush_neighbors=0，因其邻页刷新为机械硬盘设计，ssd随机iops高，启用反致无效io、写放大和延迟升高；禁用后刷脏量降20%–40%，await显著下降。

为什么 SSD 上必须设 innodb_flush_neighbors = 0

因为邻页刷新（“连坐刷脏”）是为机械硬盘的物理寻道瓶颈设计的——它把逻辑上相邻的脏页打包成一次顺序写，省掉多次磁头移动。但 SSD 没有寻道时间，随机 IOPS 高达数万，反而因强制刷一堆未必急需落盘的页，徒增无效 IO、放大写放大、拖慢单次刷脏延迟。

常见错误现象：iostat -x 1 显示 w/s 很高但业务写入量不大；Innodb_buffer_pool_pages_dirty 波动剧烈；mysqld 进程 iowait 持续 >15%，而磁盘 %util 却没打满——这往往是邻页刷新在“帮倒忙”。

• SSD 环境下该参数默认值（MySQL 8.0 前为 ON）必须显式关掉，否则后台刷脏会主动制造大量非必要写
• RAID 卡或 NVMe 多命名空间（Namespace）部署时，逻辑连续 ≠ 物理连续，邻页刷新同样失效甚至有害
• 禁用后，Innodb_buffer_pool_pages_flushed 通常下降 20%–40%，尤其在中高并发更新场景下更明显

innodb_flush_neighbors 的取值与生效条件

这个参数不是开关式布尔值，而是整型：0 表示完全禁用；1 表示只刷紧邻的一页（前或后）；2 表示刷前后各一页（共三页）。但注意——它只对 LRU List 尾部被选中刷出的脏页起作用，且仅当该页在表空间中物理地址连续时才触发。

使用场景：你正在调优一个跑在 NVMe 盘上的 OLTP 库，观察到 Innodb_pages_written 远高于 Innodb_data_writes，说明写入放大严重，此时应立刻检查此项。

• MySQL 5.7+ 默认仍为 1，需手动配成 0；8.0.22 后部分云厂商镜像已默认关，但自建环境不能依赖
• 修改后必须重启 MySQL 生效（非动态变量），且建议配合 innodb_io_capacity 重新校准（SSD 建议设 2000–4000）
• 若误设为 1 或 2，又用了 innodb_file_per_table = OFF（所有表挤在 ibdata1），邻页刷新可能跨表污染，加剧争抢

不关 innodb_flush_neighbors 的真实代价

代价不是“慢一点”，而是让 IO 负载变得不可预测：原本只需刷 1 个脏页的事务，在邻页机制下可能触发 3–7 个页的同步写，导致 await 尖刺、mysqld 响应抖动、从库 relay log 写入延迟跳升——这些在监控里都表现为毛刺，而不是平滑上升。

性能影响实测参考（某电商订单库，Intel Optane P5800X）：开启时平均 await 为 1.8ms，关闭后降至 0.3ms；高峰期 Created_tmp_disk_tables 下降 35%，因 buffer pool 更稳定，临时表更少被迫落盘。

• 它和 innodb_flush_log_at_trx_commit 不同，不涉及持久性妥协，纯属 IO 效率陷阱
• 即使 buffer pool 命中率 >99%，只要刷脏行为被邻页机制干扰，依然会看到磁盘队列堆积
• 云数据库如 RDS/Aurora 默认已关，但私有化部署的 Percona Server 或 mariadb 容易遗漏

验证是否真正生效的三个命令

别只看配置文件写了什么，要确认运行时值、刷脏行为、IO 分布是否匹配预期。

• 查当前值：select @@innodb_flush_neighbors; —— 必须返回 0
• 看刷脏模式：SHOW ENGINE INNODB STATUSG，搜索 “Pages flushed” 段，若出现 “neighbor pages flushed” 字样，说明仍在工作
• 比对 IO 特征：iostat -x 1 中对比 avgrq-sz（平均请求大小），开启时通常 >16k（因打包），关闭后回落至 4k–8k（单页或小批量）

最容易被忽略的是：改完配置忘记重启，或者用了 my.cnf 多实例加载路径（比如 /etc/my.cnf.d/ 下另有覆盖文件），结果 SELECT @@ 返回的还是旧值。真要确认，就 kill -9 进程再拉起，别信“应该生效了”。