应调大innodb日志总容量以缓解提交卡顿，但需按版本选择正确参数：5.7及之前须停库替换ib_logfile，8.0.30+用innodb_redo_log_capacity在线调整，并验证实际文件大小与innodb_log_waits归零。
调小了会卡提交，调大了恢复慢——这不是“要不要调”的问题，而是“不调就扛不住写入”的硬瓶颈。
为什么事务提交突然变慢？看 Innodb_log_waits 和 Innodb_os_log_written
事务本身不慢，但 COMMIT 阶段延迟飙升、应用报 Lock wait timeout exceeded，大概率是日志空间不够用了。InnoDB 必须等 checkpoint 刷脏页腾出日志空间，才能复用 redo log 区域，这个等待就是 Innodb_log_waits。它非零，说明日志文件太小。
- 查当前压力：
SHOW GLOBAL STATUS LIKE 'Innodb_os_log_written';，间隔 10 秒执行两次，算出每秒写入量（单位字节） - 再乘以 60～120：得到单个日志文件应覆盖的峰值 1–2 分钟写入量
- 如果每秒写 5MB，那单文件至少设为
innodb_log_file_size = 600M（5 × 60 × 2），别直接套“默认 48M” - 监控里
Innodb_log_waits > 0或SHOW ENGINE INNODB STATUS\G中 “Log sequence number” 和 “Last checkpoint at” 差值长期接近总日志容量的 70%，都是明确信号
MySQL 5.7 及更早版本必须停库删文件，否则启动直接失败
所有版本都禁止运行中修改 innodb_log_file_size，它不是动态变量。强行改配置再 reload，MySQL 启动时会校验磁盘上已有的 ib_logfile0 和 ib_logfile1 大小，不匹配就拒绝启动，错误日志里清清楚楚写着：InnoDB: Error: log file ./ib_logfile0 is of different size。
- 必须先执行：
SET GLOBAL innodb_fast_shutdown = 0（确保脏页和日志完整落盘） - 再停服务：
mysqladmin shutdown或systemctl stop mysqld，别用kill -9 - 确认进程退出后，进 datadir（如
/var/lib/mysql/），把ib_logfile0和ib_logfile1全部移走（mv ib_logfile0 ib_logfile0.bak），不能只删一个 - 改
my.cnf，例如：innodb_log_file_size = 512M，然后重启 - 启动后立刻验证：
ls -lh ib_logfile*看文件大小是否真变了，别只信配置
MySQL 8.0.30+ 改用 innodb_redo_log_capacity，支持在线调整
从 8.0.30 开始，innodb_log_file_size 和 innodb_log_files_in_group 已被废弃。继续在配置里写它们，MySQL 启动时会警告 Ignored deprecated configuration parameter，且参数无效。
- 新参数是
innodb_redo_log_capacity，单位字节，控制总 redo 日志容量（不是单个文件） - 设为
2147483648就是 2GB 总空间，InnoDB 自动拆成 32 个固定大小的文件 - 可在线改：
SET GLOBAL innodb_redo_log_capacity = 2147483648;，立即生效，无需重启 - 要持久化，得同步更新
my.cnf并删掉旧的两个参数，否则下次重启可能因冲突失败 - 注意：该功能仅限 8.0.30 及以上，别在 8.0.28 上试，会报错
调大不是万能解药，崩溃恢复时间会线性增长
日志总容量（innodb_log_file_size × innodb_log_files_in_group 或 innodb_redo_log_capacity）越大，checkpoint 越少、日常写入越顺，但代价是主库 crash 后恢复时间拉长——InnoDB 必须重放全部未刷盘的 redo 记录才能保证一致性。
- 单文件超 4G 后，恢复时间可能从几秒跳到分钟级，尤其在 HDD 或高延迟存储上
- 低写入量实例（比如日均增 10MB 数据）硬套 1G 单文件，毫无意义，反而拖慢恢复
- 别只调
innodb_log_files_in_group：它只改文件个数，不扩容缓冲能力；真正起作用的是总容量 - 调大后务必观察
SHOW ENGINE INNODB STATUS的 Log section，确认 “pending log writes” 是否回落，否则可能调错了方向
最容易被忽略的点：很多人改完配置、重启成功，就以为万事大吉，但没检查磁盘上 ib_logfile* 的实际大小是否与配置一致，也没验证 Innodb_log_waits 是否归零。日志文件是 InnoDB 的底层契约，尺寸错一点，整个恢复逻辑就不可靠。
