Redo Log总容量应设为至少1小时写入量，即innodb_log_file_size×innodb_log_files_in_group（默认2）；写密集型业务建议总容量2–4GB，OLTP约1GB，修改须停机删旧文件再重启，否则报size mismatch。
Redo Log容量和刷新策略必须一起调，单独改一个容易导致性能抖动或数据丢失风险。
如何计算并设置合适的innodb_log_file_size
总容量 = innodb_log_file_size × innodb_log_files_in_group（默认为2），这个总值应能容纳至少1小时的写入量。生产环境常见配置如下：
- 写密集型业务（如订单、日志归集）：单文件设
1G～2G，总容量 2～4GB - 一般OLTP业务：单文件
512M，总容量约1GB - 小内存或低写入场景（测试/开发）：可维持默认
512M（MySQL 8.0+）或48M（5.7）
修改前必须停机：systemctl stop mysql → 删除旧日志文件（ib_logfile0、ib_logfile1）→ 更新 my.cnf → 启动。不删旧文件直接重启会报错“log file size mismatch”。
innodb_flush_log_at_trx_commit三个取值的实际影响
该参数决定事务提交时 redo log 是否真正落盘，不是“要不要刷”，而是“刷到哪一层”：
-
1：每次COMMIT都调用fsync()写入磁盘。金融、账务类系统必须用这个值，崩溃不丢事务 -
2：写入操作系统缓存（OS cache），再由内核每秒fsync。数据库宕机不丢数据，但主机断电或OS崩溃可能丢最多1秒事务 -
0：仅写入redo log buffer，依赖后台线程每秒刷一次。性能最高，但数据库或OS任一崩溃都可能丢失最近1秒事务
压测发现吞吐瓶颈时，先检查锁等待、索引缺失、慢查询，而不是直接调成0——很多所谓“性能问题”其实是应用层批量提交不足或事务过大导致的。
为什么不能把innodb_log_buffer_size设得特别大
innodb_log_buffer_size 是内存缓冲区，只影响日志生成阶段的暂存效率，不改变磁盘日志总量。设太大反而有害：
- 默认
16M已覆盖绝大多数单事务日志量；超大事务（如百万行INSERT）才需调高到64M～256M - 超过
innodb_log_file_size的1/4 可能引发频繁 buffer flush，增加 CPU 和 I/O 压力 - 该缓冲区是全局独占的，设为几GB会挤占
innodb_buffer_pool_size，得不偿失
真正影响写性能的是日志总容量和刷盘策略，不是 buffer 大小。
容易被忽略的磁盘与路径细节
即使参数配对了，日志性能仍可能受限于底层存储：
-
innodb_log_group_home_dir默认和数据目录同路径，高并发写入时易产生 I/O 竞争；建议单独挂载 SSD 并指向新路径 - 避免将 redo log 和 undo log 放在同一物理盘上——两者都是顺序写，但恢复阶段会同时读取，竞争明显
- Linux 下确认磁盘挂载选项含
noatime和barrier=1（或使用 XFS +logbsize调优），否则 fsync 效率打折扣
最常出问题的不是参数值本身，而是日志文件位置没隔离、磁盘调度策略未优化、或者修改后忘了删旧文件——这些比选 1 还是 2 更容易让服务起不来。
