Buffer Pool 与 Redo Log 需按写入压力配比：Buffer Pool 决定脏页积压能力，Redo Log 影响 checkpoint 频率；失衡将引发 TPS 抖动、刷盘风暴或提交延迟飙升。
直接说结论：Buffer Pool 和 Redo Log 不是“调大就完事”，而是要按写入压力特征配比——Buffer Pool 决定脏页积压能力，Redo Log 决定 checkpoint 频率；两者失衡会导致 TPS 抖动、刷盘风暴或提交延迟飙升。
为什么增大 innodb_buffer_pool_size 反而让写入更慢？
常见错误现象：把 innodb_buffer_pool_size 设到物理内存 80%，但系统开始频繁 swap，show engine innodb status 显示大量 flush list 堵塞，写入延迟跳涨。
根本原因不是“不够大”，而是没配合 innodb_buffer_pool_instances 拆分实例数。单实例下所有线程争抢同一 LRU list 和 flush list 锁，高并发写入时出现严重自旋等待。
实操建议：
- 若 Buffer Pool > 8GB，必须设
innodb_buffer_pool_instances >= 8（MySQL 8.0 默认已启用，但旧配置常遗漏） - 避免跨 NUMA 节点分配：用
numactl --membind=0 mysqld绑定内存节点，防止远端内存访问放大延迟 - 上线前执行
SELECT COUNT(*) FROM information_schema.INNODB_BUFFER_POOL_PAGES_DIRTY;观察脏页占比是否长期 > 75%，超了说明刷盘跟不上，需同步调大 Redo Log
innodb_log_file_size 改多大才不触发频繁 checkpoint？
错误认知：“Redo Log 越大越好”。实际中，过大的 Redo Log 会拖慢崩溃恢复时间，且在写入突增时反而加剧单次刷盘量——因为 checkpoint 触发条件之一是“redo log 空间使用率 > 90%”，空间越大，一次腾挪的脏页越多。
真实判断依据是写入吞吐与 checkpoint 周期的匹配度：
- 用
SHOW GLOBAL STATUS LIKE 'Innodb_os_log_written';每 30 秒采样一次，计算每秒平均写入量（单位字节） - 目标 checkpoint 间隔 ≥ 60 秒 → 推荐
innodb_log_file_size = (每秒写入量 × 60) × 2（留 100% 安全余量） - MySQL 8.0+ 必须搭配
innodb_log_files_in_group=2，单文件不生效；修改后需停机重建，旧ib_logfile*必须手动移走
批量写入时 innodb_log_buffer_size 怎么设才不卡住事务？
典型场景：Java 应用用 executeBatch() 插入 1 万行，但 innodb_log_buffer_size 仅默认 16MB，导致每个 batch 都触发一次 log buffer flush 到磁盘，事务提交变慢。
关键点在于：该缓冲区只缓存事务内产生的 redo 日志，不缓存数据页本身；它影响的是“事务执行中”的日志生成效率，而非持久性保障。
- 对单事务写入量 > 1MB 的场景（如大 JSON 字段更新、批量 INSERT），建议设为
64M或128M - 不要盲目设到 512MB：buffer 过大会增加内存碎片，且 MySQL 每秒仅刷一次 log buffer（受
innodb_flush_log_at_timeout控制），过大无意义 - 验证是否生效：执行大事务前后对比
SHOW GLOBAL STATUS LIKE 'Innodb_log_waits';，值 > 0 表示 buffer 不够用，正在等刷盘
Buffer Pool 与 Redo Log 协同失效的隐藏信号
最容易被忽略的是两者的“节奏错位”：Buffer Pool 刷脏页依赖 Redo Log 空间是否充足；Redo Log 的 checkpoint 又依赖 Buffer Pool 是否有足够干净页可刷。一旦失衡，就会陷入恶性循环。
典型症状包括：
-
Innodb_buffer_pool_wait_free持续非零 → Buffer Pool 缺干净页，但 Redo Log 满导致无法 checkpoint，刷不出脏页 -
Innodb_os_log_pending_fsyncs高 +Innodb_buffer_pool_pages_dirty高 → Redo Log 刷盘慢，拖累 Buffer Pool 刷盘 - 监控图上 TPS 和
Innodb_rows_inserted波动剧烈，但 CPU/IO 并不高 → 纯内部锁竞争，非资源瓶颈
此时不能只调一个参数，必须同步检查 innodb_io_capacity（SSD 建议设为 2000+）、innodb_max_dirty_pages_pct（建议 75~85，别锁死 90）和 innodb_adaptive_flushing（务必开启）。
