innodb_flush_neighbors=0是ssd上必须关闭的伪优化参数，因其在无寻道延迟的ssd上强制批量刷邻页，导致非必要i/o放大、写延迟升高和性能抖动；mysql 5.7默认为1需手动关，8.0+默认为0但仍需验证云环境实际值。
MySQL在SSD上出现性能波动，大概率是innodb_flush_neighbors没关——它在SSD上不光没收益，还会触发非必要批量刷盘，直接拉高写延迟、放大抖动。
为什么innodb_flush_neighbors = 1在SSD上反而坏事
这个参数本意是“刷一个脏页时，顺手把物理相邻的脏页也一起刷掉”，靠合并I/O减少HDD寻道开销。但SSD没有寻道，顺序写和随机写性能差距极小，而innodb_flush_neighbors = 1会强制扫描并刷同extent内前后各一页（最多3页），哪怕其中2页刚被修改、还没来得及积累足够脏页压力，也会被提前拖下水。
常见错误现象包括：
-
SHOW ENGINE INNODB STATUS里Pages flushed突增，但业务写QPS平稳 -
Innodb_data_writes比Innodb_buffer_pool_write_requests高出2～4倍 - 慢查询日志中偶发几十到几百毫秒的写入延迟尖刺，尤其在批量更新后
怎么确认当前值并安全改到0
先查真实状态，别信配置文件里写了就算数：
SELECT @@innodb_flush_neighbors;
再确认磁盘类型是否真是SSD（避免云盘伪装成HDD）：
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修改，只能改配置+重启 - 改完别急着压测，先盯5分钟
Innodb_pages_written每秒增量，应明显回落
innodb_flush_neighbors = 0不是万能解药，要配着看
单关这个参数，效果可能被其他HDD惯性配置抵消：
-
innodb_io_capacity如果还设成200，而SSD实测随机写有80K IOPS，InnoDB后台刷脏页永远跟不上节奏，照样堆积→最终集中爆发抖动 -
innodb_flush_method仍为fdatasync时，Linux page cache和InnoDB buffer pool双缓存，内存浪费+刷盘路径变长 -
innodb_buffer_pool_size设到物理内存90%，系统OOM killer可能半夜杀掉mysqld
真正稳住SSD性能，innodb_flush_neighbors = 0只是第一刀——它切掉的是最隐蔽、最容易被忽略的“伪优化”行为。后面几刀（IO容量、刷盘方式、内存分配）缺一不可，否则抖动只是推迟，不是消失。
