innodb_log_file_size过小会导致事务提交变慢，因其迫使InnoDB频繁checkpoint、刷脏页并阻塞日志复用，引发COMMIT延迟及锁等待；应按峰值1–2分钟写入量设置，需停库删除旧日志后重启生效。
innodb_log_file_size 太小会导致 COMMIT 延迟升高
事务提交变慢，不是因为 SQL 慢，而是日志空间不够用——innodb_log_file_size 过小会迫使 InnoDB 频繁触发 checkpoint，刷脏页、等待日志复用，直接卡住后续 COMMIT。典型现象包括：Innodb_log_waits > 0、慢日志里 Query_time 集中在 commit 阶段、监控看到 Innodb_os_log_written 增速快但 TPS 上不去。
实操建议：
- 按峰值 1–2 分钟的 Redo 日志写入量估算：查
SHOW GLOBAL STATUS LIKE 'Innodb_os_log_written'，每 10 秒执行一次，算出每秒平均值，再乘以 60–120 - 单个文件建议从
512M起步，高写入场景可设为1G～4G；总容量（innodb_log_file_size × innodb_log_files_in_group）建议 ≥4G - 别只调
innodb_log_files_in_group（默认 2），它不扩容缓冲能力，只影响文件个数
innodb_flush_log_at_trx_commit=1 是写入卡顿的头号原因
这个参数设为 1，意味着每次 COMMIT 都要 fsync() 刷盘。SSD 上单次延迟约 0.3～1ms，HDD 可达 5～15ms；每秒 1000 次提交 = 每秒 1000 次磁盘强制刷写 —— IOPS 直接打满。
实操建议：
- 若业务能接受断电丢失最多 1 秒已提交事务（如日志表、行为埋点），改用
innodb_flush_log_at_trx_commit=2：日志写入 OS 缓存即返回，后台线程每秒刷一次 -
=0风险极高，仅限临时导入或压测；崩溃可能丢失整个秒级窗口的所有事务 - 单独调这个参数效果有限，必须和
sync_binlog协同调整，否则 binlog 的fsync仍会拖累
sync_binlog 和 innodb_flush_log_at_trx_commit 组合会翻倍刷盘
开启 binlog 时，sync_binlog=1 + innodb_flush_log_at_trx_commit=1 触发两阶段提交（2PC），实际是两次 fsync：一次写 redo，一次写 binlog。这不是“多一个日志同步”，而是 I/O 开销翻倍。
常见现象：show processlist 里大量线程卡在 query end 状态、iowait 持续高于 70%、TPS 上不去。
实操建议：
- 折中方案：设
sync_binlog=1000+innodb_flush_log_at_trx_commit=1，牺牲最多 1000 个事务的 binlog 持久性，Redo 刷盘压力不变，但整体 I/O 下降 99% - 若主从一致性要求不高，也可设
sync_binlog=0（依赖 OS 刷盘），但需确认从库延迟是否可接受 - 避免
sync_binlog=1+innodb_flush_log_at_trx_commit=2组合：binlog 持久但 redo 不持久，崩溃后可能无法正确回滚或恢复
调整 innodb_log_file_size 必须停机且清旧文件
这个参数不能在线修改。MySQL 启动时校验 ib_logfile0 尺寸，若与配置不符，直接报错：InnoDB: Error: log file ./ib_logfile0 is of different size。很多人删错文件、rename 代替删除、或没停干净就操作，导致启动失败。
实操建议：
- 操作前确认无活跃事务：
SELECT * FROM information_schema.INNODB_TRX;返回为空 - 停库用
mysqladmin shutdown，不要KILL进程 - 删干净
datadir下所有ib_logfile*（不止ib_logfile0），不要留备份副本 - 改配置后重启，MySQL 会自动重建日志文件；若失败，先检查错误日志是否含
log file size mismatch
真正卡写入的，往往不是磁盘本身，而是日志策略与业务节奏错配。调大 innodb_log_file_size 解的是“空间不足”问题，改 innodb_flush_log_at_trx_commit 解的是“刷得太勤”问题，而忽略 sync_binlog 的协同，等于只拧松一半螺丝。三者不一起看，优化就容易打滑。
