innodb_log_buffer_size过小导致大字段写入时redo log暴涨，需据单事务最大redo量×1.5估算并设为32M～256M，必须重启生效，且须配套调大innodb_log_file_size（≥buffer×4）及合理设置innodb_flush_log_at_trx_commit。
大字段写入时 redo log 暴涨，innodb_log_buffer_size 不够用怎么办？
当批量插入或更新含 BLOB、TEXT 的记录时，单事务产生的 redo log 可能远超默认 16MB 的 innodb_log_buffer_size。缓冲区频繁填满会触发“半满即刷盘”，导致大量小 IO，写入吞吐骤降——这不是磁盘慢，是 buffer 被撑爆了。
- 先确认是否真被卡住：执行
SHOW ENGINE INNODB STATUS\G，在LOG段看Log sequence number和Log flushed up to的差值。若持续 >50MB，说明日志积压严重 - 查监控指标：
Innodb_os_log_written（每秒写入字节数）突增 +Innodb_os_log_pending_writes非零，基本可断定 buffer 成瓶颈 - 注意：
innodb_log_buffer_size是静态参数，改完必须重启 MySQL，不能SET GLOBAL
innodb_log_buffer_size 设多大才够写大字段？
不是越大越好，关键看单事务最大 redo 量。一个含 10MB BLOB 的 UPDATE，实际生成的 redo log 可能达 12–15MB（含页头、事务元信息等）。建议按“单事务最大 redo 量 × 1.5”估算下限。
- 典型场景参考：
— 单条记录含 ≤1MB 大字段：32M 通常够用
— 批量 INSERT 100 条含 5MBTEXT的记录：至少设为 128M
— ETL 导入含 20MBBLOB的单行数据：直接设 256M - 别盲目堆内存：该 buffer 全局独占，设 512M 会吃掉半个多 GB 物理内存，且崩溃恢复时需重放全部未刷盘日志，拖长启动时间
- 配合
innodb_flush_log_at_trx_commit=2用更安全：避免=0丢数据，又比=1少一次 fsync
为什么调大了 innodb_log_buffer_size，写入速度还是没提升？
常见错觉：以为 buffer 加大就一定快。实际上，如果 redo log 文件本身太小（innodb_log_file_size），或者刷盘策略太激进（innodb_flush_log_at_trx_commit=1），buffer 再大也得每提交就 flush，起不到合并 IO 的作用。
- 检查
innodb_log_file_size：它应 ≥innodb_log_buffer_size × 4。比如 buffer 设 128M，log file 至少要 512M，否则 checkpoint 频繁，反而引发阻塞 - 观察
SHOW ENGINE INNODB STATUS中的Last checkpoint at和Log flushed up to差值：若长期 >80% 的innodb_log_file_size，说明 log file 瓶颈比 buffer 更严重 - 验证是否真减少了 IO：用
iostat -x 1看await和%util，重点对比w/s（每秒写次数）——调优后应明显下降，而非仅看吞吐量
调整后必须盯住的三个真实信号
别只看 TPS 上升就认为成功。真正有效的调优，会在底层 IO 行为和 InnoDB 内部状态上留下清晰痕迹：
-
Innodb_os_log_pending_writes从持续非零变为多数时间 = 0 -
SHOW ENGINE INNODB STATUS的LOG段中，Log sequence number与Log flushed up to的差值稳定在 10MB 以内 - 磁盘层面
iostat显示w/s下降 30%+，且await波动收敛（不再频繁冲高）
最容易被忽略的是：大字段写入往往伴随大量 undo log 生成，innodb_log_buffer_size 只管 redo，undo 压力得靠 innodb_undo_tablespaces 和 innodb_undo_log_truncate 分担——别把所有写瓶颈都归给这一个参数。
