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。乘以2是为了预留100%的安全余量。 - 注意：在 MySQL 8.0 及以上版本，必须搭配设置
innodb_log_files_in_group=2（至少两个文件），单文件配置是不生效的。修改后需要停机重建，旧的ib_logfile*文件必须手动移走。
批量写入时 innodb_log_buffer_size 怎么设才不卡住事务？
来看一个典型场景：Ja va 应用使用 executeBatch() 一次性插入上万行数据，但 innodb_log_buffer_size 还保持着默认的 16MB。结果就是，每个批次（batch）都触发一次将 log buffer 刷到磁盘的操作，事务提交速度自然就慢下来了。
这里需要理解一个关键点：这个缓冲区只缓存事务执行过程中产生的 redo 日志，并不缓存数据页本身。它影响的是“事务执行中”日志生成的效率，而不是事务最终的持久性保障。
- 对于单事务写入量超过 1MB 的场景（比如更新大 JSON 字段、批量 INSERT），建议将值设为
64M或128M。 - 但切忌盲目设到 512MB 甚至更大：过大的 buffer 会增加内存碎片。而且，MySQL 默认每秒才刷一次 log buffer（由
innodb_flush_log_at_timeout控制），设置过大并没有实际意义。 - 如何验证配置是否生效？执行一个大事务，对比执行前后
SHOW GLOBAL STATUS LIKE 'Innodb_log_waits';的值。如果该值大于 0，就说明 log 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 的刷盘（fsync）速度太慢，进而拖累了整个 Buffer Pool 的刷盘效率。- 监控图上，TPS 和
Innodb_rows_inserted剧烈波动，但 CPU 和 IO 使用率并不高：这很可能纯粹是 InnoDB 内部锁竞争导致的，并非外部资源瓶颈。
遇到这种情况，千万别只调某一个参数。必须同步检查以下几个关联配置：innodb_io_capacity（如果是 SSD，建议设为 2000 以上）、innodb_max_dirty_pages_pct（建议 75~85，不要死守默认的 90）以及 innodb_adaptive_flushing（务必确保开启）。只有协同调整，才能让整个写入链路恢复顺畅。
