调大innodb_redo_log_capacity（8.0.30+）或innodb_log_file_size（8.0.29–）是提升写入吞吐最有效的单点操作，但必须停库清理旧日志文件并修改配置，否则启动失败；需按业务峰值写入速率和checkpoint频率反推合理值，避免过小引发抖动或过大延长崩溃恢复时间。
直接结论：调大 innodb_log_file_size（MySQL 5.7/8.0.29–）或 innodb_redo_log_capacity（MySQL 8.0.30+）是提升写入吞吐最有效的单点操作，但必须停库重建日志文件，否则启动失败。
MySQL 8.0.30+ 必须用 innodb_redo_log_capacity，别写 innodb_log_file_size
MySQL 8.0.30 及之后版本已移除 innodb_log_file_size，硬写会导致启动报错：Unknown variable 'innodb_log_file_size'。初始化前必须清空配置文件中所有旧参数，只保留一行：
innodb_redo_log_capacity = 2147483648
该值单位为字节，代表 Redo Log 总容量（不是单个文件大小），InnoDB 会自动拆成约 32 个 #ib_redo* 文件。初始化命令（如 mysqld --initialize）只读配置文件，不认运行时 SET 值。
常见错误：
- 混写
innodb_log_file_size和innodb_redo_log_capacity—— 启动失败 - 初始化后执行
SET GLOBAL innodb_redo_log_capacity = ...报错 —— 说明配置文件里还有残留旧参数 - 用
ls -lh #ib_redo*看单个文件大小来判断是否生效 —— 错误，文件大小由 InnoDB 动态管理，应查SELECT @@innodb_redo_log_capacity
怎么定 innodb_log_file_size 或 innodb_redo_log_capacity 的合理值
不是拍脑袋填 1G 或 4G，而是按业务峰值写入速率和可接受的 checkpoint 频率反推：
- 先查当前写入压力：
SHOW GLOBAL STATUS LIKE 'Innodb_os_log_written'，记下数值，60 秒后再查一次，差值 ÷ 60 ≈ 每秒日志写入字节数 - 目标让 checkpoint age（
Log sequence number−Last checkpoint at）稳定在总日志容量的 70% 以下，避免频繁触发 - 按 30 秒缓冲算：比如每秒写 8MB，则总容量建议 ≥ 8 × 30 × 1024 × 1024 ≈ 2.4GB
- OLTP 场景安全区间：2GB～8GB；高吞吐 ETL 场景从 16GB 起步，但需压测崩溃恢复耗时
注意：超过 64GB 后，崩溃恢复时间非线性增长，对 SSD 随机读压力陡增；低于 2GB 在写密集场景下易引发 Innodb_os_log_written 每秒增量剧烈抖动。
改完必须停库清理旧日志，否则启动报错 InnoDB: Error: log file ./ib_logfile0 is of different size
MySQL 启动时强制校验 ib_logfile0 实际大小是否等于配置值，不一致直接退出。安全操作流程：
- 先执行
mysql -e "SET GLOBAL innodb_fast_shutdown = 0"，等脏页刷完、checkpoint 写稳 - 停服务：
systemctl stop mysqld - 备份并移走旧日志：
mv ib_logfile0 ib_logfile1 /tmp/（别用rm -f） - 改配置（MySQL 8.0.30+ 改
innodb_redo_log_capacity；老版本改innodb_log_file_size） - 启动：
systemctl start mysqld—— InnoDB 自动创建新大小的日志文件
漏掉“停库 + 清理”两步，重启必失败。很多线上事故就卡在这一步，以为改完配置就能热生效。
innodb_flush_log_at_trx_commit = 2 是提升 IOPS 最快的手段，但有前提
这个参数比调日志大小见效更快：设为 2 后，事务提交只 write() 到 OS cache，每秒统一 fsync，IOPS 可降 10 倍，TPS 反升。但它只在以下条件成立时才真正有效：
- 日志文件不能太小（至少 512MB），否则 checkpoint 仍高频触发，IO 压力只是转移而非消除
- 应用连接池必须滚动重启或自然更新 ——
SET GLOBAL生效只对新连接起作用，老连接仍按旧值执行 - 监控
Innodb_os_log_fsyncs是否从“每事务一次”变成“约每秒一次”，否则没生效 - 绝对不能用于金融、订单、账户类系统；主库开启 GTID 且从库延迟敏感时也禁用
容易被忽略的是：它和 sync_binlog 解耦，但若同时设 sync_binlog = 0，可能造成 binlog 与 redo log 落盘不同步，主从复制出错。
