调低innodb_max_dirty_pages_pct至20或30会加剧抖动，因其触发高频小批量刷页，打断查询I/O；SSD应设60～75、HDD设50～60，并关闭innodb_flush_neighbors、调优innodb_lru_scan_depth及保障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封装；检查 service 文件中是否显式启用CapabilityBoundingSet=CAP_SYS_NICE CAP_SYS_RESOURCE -
innodb_adaptive_flushing必须保持开启（默认就是 ON），它会结合 redo log 生成速率动态调整刷页节奏，比纯靠比例更稳
验证是否真起作用，别只看变量值
改完配置后，不能只跑 SHOW VARIABLES LIKE 'innodb_max_dirty_pages_pct' 就收工。真正要看的是：
-
Innodb_pages_written每秒增量是否更平稳（抖动下降 20%+ 且业务无延迟上升） -
Innodb_os_log_pending_fsyncs是否不再持续攀升（说明刷脏没滞后） -
numastat -p $(pgrep mysqld)中numa_hit是否 ≥ 90%（排除 NUMA 绑定失效干扰） -
SHOW ENGINE INNODB STATUS\G中BUF_POOL_LRU_SCAN_DEPTH单次扫描耗时是否 < 10ms
真正难的不是改哪几个数字，而是把刷页从「被动响应」变成「可预测调度」——这需要同时盯住 I/O、内存亲和性、LSN 推进速率三个维度，缺一不可。
