innodb_log_file_size过小会导致事务提交变慢，因其迫使InnoDB频繁checkpoint、刷脏页并阻塞日志复用，引发COMMIT延迟及锁等待；应按峰值1–2分钟写入量设置，需停库删除旧日志后重启生效。
为什么 innodb_log_file_size 太小会让事务提交变慢
InnoDB 每次提交事务时，必须把日志写入重做日志（redo log）并刷盘（fsync），而日志文件大小直接影响“循环写入”的频率。如果 innodb_log_file_size 设置过小，比如默认的 48MB，高并发写入下日志很快填满，InnoDB 就得频繁触发 checkpoint，强制刷脏页、等待日志空间复用——这个过程会阻塞后续事务提交，表现就是 COMMIT 延迟明显升高，甚至出现 Lock wait timeout exceeded 这类连锁反应。
常见错误现象包括：单条 INSERT 或 UPDATE 很快，但批量提交（如每 100 条 COMMIT）耗时陡增；监控看到 Innodb_os_log_written 增速快，Innodb_log_waits 不为 0；慢日志里大量事务的 Query_time 集中在 COMMIT 阶段。
-
innodb_log_file_size应至少容纳峰值 1–2 分钟的写入量（按Innodb_os_log_written增速估算） - 不能直接在线修改，需停库、删除旧日志文件、改配置、重启；否则 MySQL 启动失败并报错
InnoDB: Error: log file ./ib_logfile0 is of different size - 增大后，崩溃恢复时间可能略长（因要重放更多日志），但对日常提交性能是净收益
怎么安全调整 innodb_log_file_size
这不是改个配置 reload 就行的操作，InnoDB 对日志文件尺寸极其敏感。操作前必须确认实例已无活跃事务、无长连接未提交，并做好备份。
- 先查当前值：
SHOW VARIABLES LIKE 'innodb_log_file_size'; - 停库：
mysqladmin shutdown（不要用KILL进程） - 删旧文件：确认
datadir下的ib_logfile0和ib_logfile1已停止写入后删除（不是 rename） - 改配置：在
my.cnf的[mysqld]段落添加或修改innodb_log_file_size = 512M（建议 256M–1G，视写入压力定） - 启动：MySQL 会自动重建日志文件；若启动失败，检查错误日志是否含
log file size mismatch，大概率是旧文件没清干净
innodb_log_file_size 和 innodb_log_files_in_group 的关系
很多人以为调大 innodb_log_files_in_group（默认 2）也能缓解日志压力，其实它只影响日志文件个数，不改变总日志容量。真正决定缓冲能力的是两者乘积：innodb_log_files_in_group × innodb_log_file_size。所以优先调大后者，前者保持默认即可。
- 增大
innodb_log_files_in_group会略微增加崩溃恢复开销（需扫描更多文件），且不解决核心瓶颈 - 某些老版本 MySQL（如 5.6）对大于 4G 的单个日志文件支持不稳定，此时可考虑适度增加文件数，但仍是次要手段
- 监控关键指标：
Innodb_log_waits > 0是最直接的信号，说明日志空间不够用，必须调大
别忽略的配套调整点
单独调大日志文件效果有限，尤其在高并发 OLTP 场景。几个常被跳过的关联项会影响最终效果：
- 确保
innodb_flush_log_at_trx_commit = 1（默认），否则调大日志文件反而掩盖数据丢失风险 - 磁盘 I/O 能力必须跟上：如果用机械盘或 IOPS 不足的云盘，再大的日志文件也卡在 fsync 上；建议监控
io_wait和fsync延迟 - 避免和
sync_binlog形成双重刷盘放大：若 binlog 也开启同步（sync_binlog = 1），每次 COMMIT 实际触发两次磁盘刷写，此时调大日志文件只能缓解一半压力
真正卡住提交的，往往是日志空间 + 磁盘吞吐 + 刷盘策略三者叠加的结果。只盯着 innodb_log_file_size 改，容易在 SSD 云盘上见效，在 HDD 或低配实例上依然缓慢——这点最容易被忽略。
