应设为SSD环境60～75、HDD环境50～60、高频写入场景75～80，避免设5或10导致刷页高频抖动；需同步调优innodb_io_capacity、innodb_lru_scan_depth及开启adaptive_flushing。
别设成 5 或 10 —— 这会让刷页更抖、查询更卡，不是“越低越稳”，而是越碎越崩。
innodb_max_dirty_pages_pct 设多少才不抖
这个参数不是“脏页危险阈值”，而是后台刷页节奏的触发开关。设太低（比如 20 或 30），InnoDB 会在脏页刚超线时就小批量刷一次，导致刷页线程高频唤醒、打断查询 I/O 调度。
实操建议：
- SSD 环境：设为
60～75，给后台留出平滑刷页窗口，避免毛刺 - HDD 环境：设为
50～60，防止刷页争抢本就紧张的磁盘带宽 - 高频写入场景（如日志表密集写）：可试探性设到
75～80，但必须同步观察Innodb_os_log_pending_fsyncs是否持续攀升 - 别在线
SET GLOBAL innodb_max_dirty_pages_pct = X后就认为生效——已有脏页仍按旧策略处理，新策略只影响后续刷页决策
为什么调了 innodb_max_dirty_pages_pct 却没效果
常见原因不是参数没改对，而是被其他隐性开关卡住了节奏：
-
innodb_lru_scan_depth默认是1024，高并发写入下容易引发 LRU 链表扫描锁争用，拖慢整个刷脏流程；SSD 可压到256或512，HDD 建议128或更低 -
innodb_io_capacity没匹配磁盘真实能力：SSD 实测随机写 IOPS 是 3000，却还用默认200，再调innodb_max_dirty_pages_pct也没用 -
innodb_adaptive_flushing关闭时，刷页完全依赖脏页比例；开启后会结合 redo log 生成速率动态调整，更适合写入波动大的业务 - NUMA 绑定失效：
numastat -p $(pgrep mysqld)显示numa_hit< 90%，说明刷页时从远端节点分配内存，引发跨 NUMA 访问和换页风暴
innodb_flush_neighbors 在 SSD 上必须关
这个参数控制刷一个脏页时是否顺带刷物理相邻的脏页。在 HDD 上能合并随机写为顺序写，但在 SSD 上毫无收益，反而浪费 I/O 带宽、拉高延迟。
实操要点：
- 先确认存储类型：
cat /sys/block/*/queue/rotational，输出0表示 SSD - 动态关闭：
SET GLOBAL innodb_flush_neighbors = 0 - 永久生效：在
my.cnf的[mysqld]段加innodb_flush_neighbors = 0 - 值为
1（刷前后各一页）和2（刷整个 extent，64 页）在生产环境基本不用；尤其2容易引发 I/O 尖刺，看到配置为2基本可判定失误
验证是不是真起作用，不能只看变量值
改完配置后，真正要看的是刷页行为是否收敛、业务是否平稳：
- 盯
Innodb_pages_written每秒增量：抖动下降 20%+ 且业务无延迟上升才算有效 - 查
Innodb_os_log_pending_fsyncs：不再持续攀升，说明刷脏没滞后于 redo 写入 - 观察
SHOW ENGINE INNODB STATUS\G中的BUF_POOL_FLUSH_LRU速率：从忽高忽低变成稳定区间波动 - 对比
iostat -x 1的await和%util：毛刺减少、曲线更平滑
最常被忽略的一点：刷页节奏是否稳定，不取决于你设了多少，而取决于 innodb_io_capacity 是否真实、innodb_lru_scan_depth 是否松绑、以及 NUMA 是否兜住——三者缺一，调 innodb_max_dirty_pages_pct 就只是在调一个假开关。
