innodb_log_file_size过小会导致频繁checkpoint，降低写入性能；建议单文件设1–2gb，总容量覆盖15–30分钟峰值写入量，调整前需停库清理旧日志文件。
innodb_log_file_size 设置太小导致频繁 checkpoint
MySQL 在写事务日志（redo log）时，如果 innodb_log_file_size 过小，log 文件很快填满，触发强制 checkpoint，把脏页刷盘。这会明显拖慢写入吞吐，尤其在批量插入或高并发更新场景下，SHOW ENGINE INNODB STATUS 里常看到 “Log sequence number” 追着 “Log flushed up to” 跑，差值长期压不下来。
实操建议：
-
innodb_log_file_size建议设为 1–2GB（单个文件），总 redo log 容量（innodb_log_files_in_group×innodb_log_file_size）至少覆盖 15–30 分钟的峰值写入量 - 调整前必须停库，删掉旧
ib_logfile*文件（或用mysqld --innodb-log-file-size=...启动自动重建） - 增大后，crash recovery 时间可能略长，但日常写入延迟下降显著；线上调大前建议在备库先验证
- 注意磁盘空间：总 redo log 占用是两倍（双写 + 当前使用中），别和
innodb_buffer_pool_size争 SSD 空间
innodb_flush_log_at_trx_commit = 2 时丢数据风险与权衡
默认值 innodb_flush_log_at_trx_commit = 1 表示每次事务提交都 fsync 到磁盘，最安全但性能最差；设成 2 是折中方案：日志写入 OS 缓存即返回成功，每秒才真正刷盘。它能大幅缓解磁盘 I/O 瓶颈，但主机断电或 mysqld 进程崩溃会导致最多 1 秒事务丢失。
实操建议：
- 仅在业务允许“秒级数据丢失”的场景用
2（如日志表、埋点数据、非核心状态更新） - 绝对不要在金融、订单、账户余额类业务中设为
2，哪怕只有一张表涉及资金流转 - 搭配
sync_binlog = 1使用时，innodb_flush_log_at_trx_commit = 2会造成 binlog 和 redo log 不一致，主从复制可能出错 - 监控
Innodb_os_log_pending_fsyncs状态变量，持续 > 0 说明 OS 缓存积压严重，2可能已不够用
innodb_log_buffer_size 太小引发额外内存拷贝
事务产生的 redo 日志先写入内存 buffer（innodb_log_buffer_size），再批量刷到磁盘 log 文件。如果 buffer 太小（默认 16MB），大事务或含大量 BLOB/TEXT 的语句会频繁触发 buffer flush，产生多余内存拷贝和锁竞争，SHOW STATUS LIKE 'Innodb_log_waits' 计数上升就是信号。
实操建议：
- 观察
Innodb_log_waits是否 > 0；若持续增长，优先调大innodb_log_buffer_size - 一般设为 32–64MB 即可，无需超过 128MB；它不参与 buffer pool 管理，但过大仍浪费内存
- 该参数可在线动态修改（MySQL 5.7+），无需重启：
SET GLOBAL innodb_log_buffer_size = 67108864; - 注意：buffer size 只影响“写入 buffer”阶段，不改变日志落盘时机，不能替代
innodb_flush_log_at_trx_commit的取舍
SSD 耐久性与日志刷盘频率的隐性冲突
高频 fsync（比如 innodb_flush_log_at_trx_commit = 1 + 高 TPS）会让 SSD 的 write endurance 快速消耗，尤其在低端 NVMe 或 SATA SSD 上，iostat -x 可见 await 波动剧烈、%util 长期 95%+，此时性能瓶颈已不在 MySQL 层，而在硬件响应能力。
实操建议：
- 确认磁盘是否支持
fsync优化：用hdparm -I /dev/nvme0n1 | grep "Write cache"查看是否启用 write cache；未启用则 fsync 实际是直写 NAND，延迟极高 - 生产环境务必关闭磁盘 write cache（
hdparm -W0 /dev/nvme0n1），否则innodb_flush_log_at_trx_commit = 1形同虚设 - 若硬件无法兼顾低延迟与高耐久，考虑将 redo log 放在专用高性能 NVMe（如 Intel Optane）上，而非和 data file 共享同一块盘
- 监控
Innodb_os_log_written每秒字节数，超 50MB/s 且磁盘avgqu-sz> 2 就该怀疑底层 I/O 已饱和
redo log 参数不是孤立调优项，它和 buffer pool、binlog、磁盘队列深度、甚至应用层事务粒度强耦合。最容易被忽略的是：调大 innodb_log_file_size 后没清空旧文件就重启，MySQL 会静默降级回默认 48MB，而你完全看不到报错。
