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，而你完全看不到报错。
评论(0)