innodb_flush_neighbors=0是ssd上必须关闭的伪优化参数，因其在无寻道延迟的ssd上强制批量刷邻页，导致非必要i/o放大、写延迟升高和性能抖动；mysql 5.7默认为1需手动关，8.0+默认为0但仍需验证云环境实际值。
innodb_flush_neighbors = 0 是 SSD 上必须关掉的“伪优化”，不关它，抖动就藏在每次批量刷邻页的动作里——看似省 I/O，实则放大写延迟。
为什么 innodb_flush_neighbors = 1 在 SSD 上反而坏事
这个参数本意是“刷一个脏页时，顺手把物理相邻的脏页也一起刷掉”，对 HDD 有用（减少寻道）。但 SSD 没寻道延迟，顺序写和随机写性能几乎一样，innodb_flush_neighbors = 1 却强制扫描同 extent 内前后最多 2 个页（共最多 3 页），哪怕那两个页刚被修改、根本没到刷盘节奏，也被拖进本次 I/O。结果就是：
- 实际写入量比业务需要多出 2～4 倍（
Innodb_data_writes远高于Innodb_buffer_pool_write_requests） -
SHOW ENGINE INNODB STATUS里Pages flushed突增，但业务 QPS 平稳 - 慢查询日志中偶发几十～几百毫秒写入延迟尖刺，尤其批量更新后
怎么确认并安全设成 0
别只看配置文件，运行时值才作数：
- 查当前值：
SELECT @@innodb_flush_neighbors; - 确认磁盘真是 SSD：
cat /sys/block/nvme0n1/queue/rotational（输出0才是 SSD；注意设备名按实际替换） - 动态生效（立即起效，重启丢失）：
SET GLOBAL innodb_flush_neighbors = 0; - 永久生效：在
my.cnf的[mysqld]段加一行innodb_flush_neighbors = 0
注意：MySQL 5.7 默认是 1，8.0+ 默认是 0，但云厂商镜像或旧实例常保留老默认值；Group Replication 从节点、只读实例不支持 SET GLOBAL，只能改配置+重启。
innodb_flush_neighbors = 0 不是万能解药
单关这个参数，效果常被其他 HDD 惯性配置抵消：
-
innodb_io_capacity还设成200？SSD 实测随机写有 80K IOPS，后台刷页永远跟不上，脏页堆积→集中爆发抖动 -
innodb_flush_method仍是fdatasync？Linux page cache 和 InnoDB buffer pool 双缓存，路径变长、内存浪费 -
innodb_buffer_pool_size设到物理内存 90%？系统 OOM killer 可能半夜杀掉mysqld
真正稳住 SSD 性能，innodb_flush_neighbors = 0 只是第一刀——它切掉的是最隐蔽、最容易被忽略的“伪优化”行为。后续必须同步调 innodb_io_capacity（建议用 fio 测真实 IOPS）、验证 innodb_max_dirty_pages_pct（SSD 推荐 60～75）、检查 NUMA 绑定是否生效，否则抖动只是换个方式回来。
