脏页刷新不是越勤快越稳，设innodb_max_dirty_pages_pct为20或30反而加剧抖动；该参数是刷页节奏开关而非危险阈值，ssd建议60～75、hdd建议50～60，需同步关闭innodb_flush_neighbors、调优innodb_lru_scan_depth和innodb_io_capacity，并验证innodb_pages_written抖动下降20%+及numa_hit≥90%。
脏页刷新不是“越勤快越稳”，设 innodb_max_dirty_pages_pct 为 20 或 30 反而会让抖动更明显——这是线上最常踩的坑。
为什么调低 innodb_max_dirty_pages_pct 会加重抖动
这个参数不是“脏页危险阈值”，而是后台刷页节奏的触发开关。设太低（比如 20），InnoDB 会在脏页刚超线时就小批量刷一次，导致刷页线程高频唤醒，打断查询 I/O 调度。
- 常见错误现象：
Innodb_buffer_pool_pages_dirty在 1k–3k 区间反复跳变；iostat -x 1显示await毛刺明显、%util波动剧烈 - SSD 环境推荐设为 60～75，给后台留出平滑刷页窗口
- HDD 环境建议 50～60，防止刷页争抢本就紧张的磁盘带宽
- 高频写入场景（如日志表）可试 75～80，但必须同步观察
Innodb_os_log_pending_fsyncs是否持续攀升 -
SET GLOBAL innodb_max_dirty_pages_pct = X后，已有脏页仍按旧策略处理，新策略只影响后续刷页决策
innodb_flush_neighbors = 1 在 SSD 上是隐形抖动源
该参数在 HDD 上能合并随机写为顺序写，但在 SSD 上毫无收益，反而强制扫描同 extent 内最多 2 个邻页，造成非必要 I/O 放大和延迟升高。
- 确认是否真为 SSD：
cat /sys/block/nvme0n1/queue/rotational（输出 0 才是 SSD；设备名按实际替换） - 查当前值：
SELECT @@innodb_flush_neighbors; - 动态关闭：
SET GLOBAL innodb_flush_neighbors = 0;（MySQL 5.7 默认为 1，务必手动关） - 永久生效：在
my.cnf的[mysqld]段加innodb_flush_neighbors = 0 - 注意：Group Replication 从节点、只读实例不支持
SET GLOBAL，只能改配置+重启
刷页卡顿常被 innodb_lru_scan_depth 和 NUMA 绑定失效掩盖
即使 innodb_max_dirty_pages_pct 和 innodb_io_capacity 都调对了，抖动仍存在，大概率是这两个隐性开关没兜住。
-
innodb_lru_scan_depth默认 1024，高并发写入下易引发 LRU 链表扫描锁争用；SSD 可压到 256 或 512，HDD 建议 128 或更低 -
numastat -p $(pgrep mysqld)中numa_hit＜ 90%，说明刷页时从远端节点分配内存，触发跨 NUMA 访问和换页风暴 - systemd 启动的 mysqld 很容易漏掉
numactl封装；检查systemdservice 文件中是否显式启用CapabilityBoundingSet=CAP_SYS_NICE CAP_SYS_RESOURCE - 验证 LRU 扫描效率：
SHOW ENGINE INNODB STATUS\G中BUF_POOL_LRU_SCAN_DEPTH单次扫描耗时应 ＜ 10ms
验证优化是否真起作用，不能只看变量值
改完配置后，不能只跑 SHOW VARIABLES LIKE 'innodb_max_dirty_pages_pct' 就收工。真正要看的是指标变化：
-
Innodb_pages_written每秒增量是否更平稳（抖动下降 20%+ 且业务无延迟上升） -
Innodb_os_log_pending_fsyncs是否不再持续攀升（说明刷脏没滞后） -
numastat -p $(pgrep mysqld)中numa_hit是否 ≥ 90% -
SHOW ENGINE INNODB STATUS\G中BUF_POOL_FLUSH_LRU刷页速率是否忽高忽低
复杂点在于：所有参数都有关联性，单独调一个几乎没用；innodb_flush_neighbors = 0 是第一刀，但若 innodb_io_capacity 还卡在默认 200，SSD 实测 IOPS 是 80K，刷页永远跟不上，抖动只是换个方式回来。
