innodb_flush_neighbors 会影响写操作延迟，因为它在刷脏页时额外刷新邻接页，ssd上反而增加i/o负载、延长单次刷页时间，拖慢事务提交；原为hdd优化的设计在ssd上适得其反。
为什么 innodb_flush_neighbors 会影响写操作延迟？
MySQL 写入变慢，尤其在 SSD 上还明显卡顿，常被忽略的一个点就是 innodb_flush_neighbors。它控制 InnoDB 刷脏页时是否顺带把“邻接页”（同一区 extent 内的其他脏页）一起刷掉。这个策略原本为传统机械盘（HDD）设计——顺序写比随机写快得多；但对 SSD 来说，随机写性能接近顺序写，额外刷邻接页反而增加 I/O 负载、延长单次刷页时间，拖慢事务提交响应。
典型表现是：SHOW ENGINE INNODB STATUS 中看到大量 flushing log 或 waiting for flush 状态，innodb_buffer_pool_wait_free 计数上升，且磁盘 iowait 高但吞吐并不饱和。
怎么安全地关掉邻接页刷新？
直接改配置最有效，但要注意生效时机和兼容性：
-
SET GLOBAL innodb_flush_neighbors = 0可立即生效，无需重启，但仅影响后续刷页行为；已排队的刷页任务不受影响 - 必须同步修改配置文件（如
/etc/my.cnf），否则重启后恢复默认值（MySQL 5.6+ 默认为 1） - 仅对
innodb_file_format = Barracuda且innodb_page_size = 16k有效；若用压缩表或非标准页大小，效果可能受限 - SSD 环境下建议设为 0；如果是 HDD 或混合存储，保留 1 更稳妥
配置示例：
[mysqld] innodb_flush_neighbors = 0
关掉之后要盯哪些指标？
不是一关就万事大吉，得验证是否真起效、有没有副作用：
- 观察
Innodb_buffer_pool_pages_dirty是否稳定在较低水位（SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_dirty'），飙升说明刷页压力转移但没缓解 - 检查
innodb_log_waits是否增长——如果日志写满频率上升，说明刷脏页变慢导致 log buffer 积压，这时可能需要调大innodb_log_file_size - 对比
sys.schema_table_statistics中写密集表的avg_timer_wait，确认 UPDATE/INSERT 延迟是否下降 - 留意
io_stat中单次 I/O 大小：关掉后平均 I/O size 应明显变小（从几 MB 降到几十 KB），说明不再批量刷邻接页
它和 innodb_io_capacity 是什么关系？
这两个参数常被一起调，但作用层面不同：innodb_io_capacity 控制刷页“节奏”（每秒最多刷多少页），而 innodb_flush_neighbors 控制刷页“范围”。即使 innodb_io_capacity 设得很高，邻接页机制仍会让单次刷页操作更重、更阻塞。
- 如果你已经调高了
innodb_io_capacity（比如设到 2000），但写延迟依旧高，大概率是邻接页在捣鬼 - 两者可叠加优化：先关
innodb_flush_neighbors，再根据实际 I/O 能力微调innodb_io_capacity - 注意
innodb_io_capacity_max应设为innodb_io_capacity的 2–3 倍，避免突发脏页高峰时刷不过来
