调大innodb_log_buffer_size仅在大事务、批量导入或innodb_log_waits持续非零时有效；动态调整需同步配置文件，且不能超innodb_log_file_size的1/2，须配合innodb_log_file_size和innodb_flush_log_at_trx_commit协同优化。
调大 innodb_log_buffer_size 能提升吞吐量，但只在特定场景下有效——它不解决磁盘 I/O 瓶颈本身，而是减少因缓冲区填满导致的额外刷盘和内存拷贝开销。
什么时候调大 innodb_log_buffer_size 真的有用
这个缓冲区只缓存「未提交事务」产生的 redo 日志，不是所有日志都走它。真正受益的场景很窄：
- 单个事务写入量大（比如一条
INSERT ... SELECT批量插入上万行，或含大量BLOB/TEXT字段） - 批量导入时用
LOAD DATA INFILE且未分事务 - 监控发现
Innodb_log_waits持续非零（说明 buffer 不够，被迫等刷盘后才能继续写） - 应用里显式开启长事务，中间做了密集 DML（如循环更新 5000 行后才
COMMIT）
普通 OLTP 业务（每条 SQL 日志几 KB）、短事务为主的应用，innodb_log_buffer_size = 16M 已足够。设成 64M 或更大反而浪费内存，还可能挤占 innodb_buffer_pool_size。
怎么安全地改 innodb_log_buffer_size
它是动态参数，运行时可调，但要注意生效范围和边界限制：
- 执行
SET GLOBAL innodb_log_buffer_size = 33554432;（即 32M），立即对新连接生效；已有连接仍用旧值（不影响一致性） - 必须同步修改配置文件（如
/etc/my.cnf的[mysqld]段），否则重启后还原 - 不能超过
innodb_log_file_size的 1/2，否则 MySQL 启动失败（例如innodb_log_file_size = 512M，那 buffer 最大只能设到 256M） - 推荐用单位后缀写法：
SET GLOBAL innodb_log_buffer_size = 32M;，比硬写字节数更清晰、不易错
怎么验证有没有效果，而不是白调
别只看变量值是否变了，重点看行为是否改善：
- 查等待：执行
SHOW GLOBAL STATUS LIKE 'Innodb_log_waits';，如果数值不再增长或归零，说明 buffer 不再成为瓶颈 - 估压力：用
SHOW ENGINE INNODB STATUS\G，找 “Log sequence number” 和 “Log flushed up to”，差值除以时间（秒），得到峰值日志生成速率（B/s）。若该速率常接近你设的 buffer 大小（比如 32M buffer，但峰值日志生成达 25MB/s），那 buffer 还是偏小 - 看副作用：检查
Innodb_os_log_pending_writes是否明显下降，同时用iostat -x 1观察磁盘 %util 和 await 是否降低——如果没变化，说明瓶颈不在这里（可能是磁盘本身慢，或innodb_flush_log_at_trx_commit设为 1 导致强制刷盘）
最容易被忽略的是：调大 innodb_log_buffer_size 单独起不了作用。它必须和 innodb_log_file_size（决定 checkpoint 频率）、innodb_flush_log_at_trx_commit（决定刷盘时机）配合使用。比如 buffer 调大了，但日志文件太小（如仍为默认 48M），照样会频繁触发 checkpoint，吞吐量还是上不去。
