innodb_log_buffer_size过小会导致COMMIT阻塞，因其容量不足迫使事务频繁等待日志缓冲区刷盘；需配合innodb_log_file_size合理设置，否则仅转移瓶颈而非解决。
调大 innodb_log_buffer_size 能缓解事务提交阻塞，但必须配合 innodb_log_file_size 合理设置，否则只是把问题从“刷盘卡”转移到“checkpoint 卡”。
为什么 innodb_log_buffer_size 过小会导致 COMMIT 阻塞
事务日志不是直接写磁盘的：先写进内存缓冲区（innodb_log_buffer_size），等满、或事务提交、或后台线程触发时，才批量刷到 redo log 文件。默认仅 8MB（MySQL 5.6）或 16MB（5.7+），在以下场景会频繁触发隐式 flush：
- 单事务修改大量行（如含 BLOB/TEXT 字段）
- 高并发下小事务密集提交（buffer 来不及刷就被挤满）
-
innodb_log_waits > 0出现，说明 buffer 不够用，事务在等 flush 完成
此时你看到的现象是：单条 INSERT 很快，但批量 COMMIT（比如每 100 行一次）耗时陡增，慢日志里 Query_time 集中在 COMMIT 阶段。
怎么安全设置 innodb_log_buffer_size
它可在线调整（SET GLOBAL innodb_log_buffer_size = 67108864），但注意：
- 新值只对后续连接生效；已连接会话仍用旧 buffer，需重连才感知
- 不能设得过大（如 > 256MB），否则浪费内存，且单次 flush 压力反而升高
- 建议按业务最大单事务日志量设：若某事务产生约 40MB redo 日志，buffer 至少设为 64MB
- 搭配监控：
SHOW STATUS LIKE 'Innodb_log_waits'应长期为 0；若仍 > 0，说明 buffer 还不够，或根本是innodb_log_file_size太小导致 checkpoint 频繁反压
innodb_log_buffer_size 和 innodb_log_file_size 必须协同调
只调 buffer 不调文件大小，是常见误区。二者关系是：
-
innodb_log_buffer_size决定“写多快”，innodb_log_file_size决定“能存多久” - 官方建议：
innodb_log_file_size ≥ innodb_log_buffer_size × 4；例如 buffer 设 64MB，log file 至少要 256MB - 若 buffer 是 128MB，但
innodb_log_file_size还是默认 48MB，那 buffer 刷得再快，redo 文件几秒就写满，立刻触发 checkpoint —— 最终还是卡在 COMMIT - 验证是否匹配：查
SHOW ENGINE INNODB STATUS\G，看 “Log sequence number” 和 “Last checkpoint at” 差值，若长期 > 70% × (innodb_log_file_size×innodb_log_files_in_group)，说明文件太小，光调 buffer 没用
容易被忽略的坑：别只盯 buffer，先确认是不是大事务设计问题
很多“日志缓冲不足”其实是应用层问题：
- 一个事务更新 50 万行？这不是调参数能救的，应该拆成每 1 万行一次 COMMIT
- BLOB 字段未压缩、未分离存储，导致单行日志膨胀数 MB，
innodb_log_buffer_size再大也扛不住 - 错误地认为
max_allowed_packet调大就能解决，但它管的是客户端通信包，和 redo buffer 完全无关 - 误删
ib_logfile*后没改配置就重启，MySQL 启动失败报InnoDB: Error: log file ./ib_logfile0 is of different size—— 这是innodb_log_file_size的锅，不是 buffer 的
真正要动手调 buffer 前，先跑一遍 SHOW STATUS LIKE 'Innodb_log_waits' 和 SHOW GLOBAL STATUS LIKE 'Innodb_os_log_written'，确认瓶颈确实在内存缓冲，而不是日志文件容量或事务逻辑本身。
