MySQL的事务日志是InnoDB私有的redo log，非binlog；其大小调整需停机操作，通过修改innodb_log_file_size并手动替换文件实现；与binlog通过两阶段提交协同保障ACID。
MySQL 的事务日志（redo log）由 InnoDB 自主管理，不依赖 binlog
MySQL 本身不提供“事务日志”的独立配置接口，真正实现事务持久性的 redo log 是 InnoDB 存储引擎私有的日志系统，和 server 层的 binlog 完全分离。这意味着：启用事务、崩溃恢复、刷盘节奏等行为都由 InnoDB 控制，my.cnf 中相关参数也全属 innodb_* 前缀。
常见误区是把 binlog 当作事务日志——它只记录逻辑写操作，不保证单个事务的原子性恢复；而 redo log 记录的是物理页变更，用于崩溃后重放未刷盘的脏页。
-
innodb_log_file_size决定每个 redo log 文件大小，总容量为innodb_log_files_in_group × innodb_log_file_size；增大可降低 checkpoint 频率，但会延长崩溃恢复时间 -
innodb_log_buffer_size控制内存中 redo 日志缓冲区大小，大事务建议调高（如 8M～16M），避免频繁刷入磁盘 -
innodb_flush_log_at_trx_commit是关键开关：设为1（默认）表示每次事务提交都fsync到磁盘，强一致性；设为0或2会牺牲一定持久性换性能
如何安全调整 InnoDB redo log 文件大小
修改 innodb_log_file_size 不是改完配置重启就能生效——InnoDB 要求 redo log 文件组大小与当前实际文件完全匹配，否则拒绝启动，并报错：InnoDB: Error: log file ./ib_logfile0 is of different size。
必须按顺序执行以下步骤：
- 确认当前设置：
SHOW VARIABLES LIKE 'innodb_log%'; - 正常关闭 MySQL：
mysqladmin shutdown（不能 kill -9） - 备份并删除旧日志文件（通常为
ib_logfile0、ib_logfile1） - 修改
my.cnf中的innodb_log_file_size，再启动 MySQL；InnoDB 会自动创建新大小的日志文件
注意：5.7+ 版本支持在线调整（需配合 innodb_log_online_alter_log_groups），但仅限增加数量，不支持动态改单个文件大小。
binlog 和 redo log 如何协同保障 ACID
MySQL 主从复制和崩溃恢复需要两者配合，但职责完全不同：
-
redo log是 InnoDB 引擎层日志，作用域是单实例崩溃恢复，只在本地有效 -
binlog是 server 层日志，格式可选STATEMENT/ROW，用于主从同步、审计、闪回，不参与崩溃恢复 - 两阶段提交（2PC）确保二者一致性：事务提交时先写
redo logprepare，再写binlog，最后写redo logcommit；crash 后通过binlog中已写入的 XID 对照redo log决定是否提交
若关闭 binlog（skip-log-bin），则无法使用主从、GTID、PXB 备份等能力；若关闭 redo log（不可行，InnoDB 依赖它），数据库根本无法启动。
查看和诊断 redo log 状态的关键命令
日常运维中，不能只看配置，更要观察运行时状态。以下命令能快速定位日志压力或瓶颈：
-
SHOW ENGINE INNODB STATUS\G→ 查看LOG小节中的Log sequence number、Log flushed up to、Last checkpoint at，三者差距过大说明刷盘慢或 checkpoint 滞后 -
SELECT * FROM information_schema.INNODB_METRICS WHERE NAME IN ('log_os_waits', 'log_writes', 'log_write_requests');→ 监控写日志的等待和频率 -
innodb_log_waits状态变量非零，代表 log buffer 不够用，被迫等待刷盘完成，此时应增大innodb_log_buffer_size
特别注意：innodb_log_file_size 过小会导致频繁 checkpoint，引发 I/O 尖刺；过大则 recovery 时间长，且占用更多磁盘空间——没有银弹，需结合写负载、RPO/RTO 要求权衡。
