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 STATUS\G，搜索 “Pages flushed” 段，若出现 “neighbor pages flushed” 字样，说明仍在工作 - 比对 IO 特征：
iostat -x 1中对比avgrq-sz（平均请求大小），开启时通常 >16k（因打包），关闭后回落至 4k–8k（单页或小批量）
最容易被忽略的是：改完配置忘记重启，或者用了 my.cnf 多实例加载路径（比如 /etc/my.cnf.d/ 下另有覆盖文件），结果 SELECT @@ 返回的还是旧值。真要确认，就 kill -9 进程再拉起，别信“应该生效了”。
