根本原因是innodb_buffer_pool_size不足且innodb_max_dirty_pages_pct设置过高（默认90），导致脏页积压触发强制同步刷新，使前台线程阻塞等待log_flush_order_mutex或buf_pool->mutex；应设innodb_max_dirty_pages_pct=75、innodb_io_capacity=2000、innodb_io_capacity_max=4000，并禁用自适应刷新，同时分批更新（每批100–500行）、显式提交、批次间休眠以缓解压力。
为什么大批量 UPDATE 会卡住 Buffer Pool 刷新？
根本原因不是 SQL 慢，而是 innodb_buffer_pool_size 不足 + innodb_max_dirty_pages_pct 设置过激，导致脏页积压后触发强制同步刷新（sync flush），阻塞后续 DML。InnoDB 在后台线程（page_cleaner）来不及处理时，会把刷新压力“甩”给前台线程——你看到的 Updating 状态长时间不动，其实是线程在等 log_flush_order_mutex 或 buf_pool->mutex。
如何调低脏页刷新对业务的影响？
关键不是关掉刷新，而是让刷新更平滑、更可预期：
-
innodb_max_dirty_pages_pct = 75（默认 90）：留出缓冲空间，避免临界点突增刷新压力 -
innodb_io_capacity = 2000（按 SSD 实际 IOPS 调整）：告诉 InnoDB 你能扛多快的刷盘节奏 -
innodb_io_capacity_max = 4000：允许突发场景下短时加速，但不长期透支 - 禁用
innodb_adaptive_flushing = OFF（MySQL 8.0+ 默认 ON）：自适应逻辑在高更新密度下反而抖动更大，固定节奏更稳
批量 UPDATE 本身该怎么写才不拖垮 Buffer Pool？
单条 UPDATE ... WHERE id IN (1,2,...,5000) 是最危险的写法——它一次性生成大量脏页，且无法被 page_cleaner 分摊。正确做法是分片 + 控制事务粒度：
- 每批最多 100–500 行（具体看行大小和索引复杂度），用
LIMIT+WHERE id > ? ORDER BY id LIMIT 500 - 显式加
COMMIT，避免长事务拖住undo log和脏页链表 - 避开高峰期执行；若必须在线，加
SLEEP(0.1)在批次间，给 page_cleaner 留出追赶时间 - 确认
innodb_flush_log_at_trx_commit = 1（别为提速改成 2，否则 crash 后丢数据）
怎么验证脏页压力是否真的缓解了？
别只看 SHOW ENGINE INNODB STATUS 里的 “Buffer pool hit rate”，要看实时指标：
-
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_wait_free'：非零说明 buffer pool 频繁缺空闲页，需扩容或降负载 -
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_dirty'：持续 > 10% 总页数就预警 - 监控
Innodb_data_fsyncs和Innodb_log_waits：后者非零代表 redo log 写满等待，说明刷盘跟不上
真正难的是平衡：刷太快耗 I/O，刷太慢卡事务。没有银弹配置，只有根据你的硬件、QPS、更新频率反复测出来的阈值。
