MySQL日志系统由redo log、undo log、binlog及其他辅助日志协同构成：redo log保障崩溃恢复，undo log支撑事务回滚与MVCC，binlog用于主从复制和逻辑恢复，error/slow/general log辅助运维诊断，各日志通过两阶段提交机制保持一致性。
MySQL 的日志系统不是单一文件，而是一组分工明确、协同工作的日志模块，各自承担不同职责：记录事务变更、保障崩溃恢复、追踪执行过程、审计操作行为等。理解它们的类型、作用时机、存储位置和相互关系，是排查问题、优化性能和设计高可用架构的基础。
redo log（重做日志）：崩溃恢复的核心保障
redo log 是 InnoDB 存储引擎特有的物理日志，记录的是“在某个数据页上做了什么修改”，比如“将第 5 号页的偏移量 100 处的值从 0x12 写成 0x34”。它采用循环写入方式，由多个固定大小的文件组成（如 ib_logfile0、ib_logfile1），写满后自动覆盖最旧部分。
- 作用发生在事务提交前：只要 redo log 落盘（刷到磁盘），即使数据库突然宕机，重启后也能根据日志重放未写入数据页的变更，保证已提交事务的持久性（Durable）
- 不直接记录 SQL 语句，也不关心逻辑含义，只关注页级物理变更，因此写入极快
- 通过 innodb_log_file_size 和 innodb_log_files_in_group 控制大小与数量；innodb_flush_log_at_trx_commit 决定刷盘策略（0/1/2），直接影响性能与安全性权衡
undo log（回滚日志）：事务原子性与 MVCC 的基础
undo log 也是 InnoDB 管理的逻辑日志，保存的是“事务执行前的数据旧值”，例如“某行原来的名字是张三，现在要改成李四，就记下‘张三’这个旧值”。它被组织成链表结构（rollback segment），按事务隔离级别参与多版本并发控制（MVCC）。
- 支持事务回滚：若事务中途失败或显式执行 ROLLBACK，InnoDB 用 undo log 将修改逆向还原
- 支撑一致性读：SELECT 查询在 RC 或 RR 隔离级别下，会依据 read view 和 undo log 构建历史版本，避免读到未提交或已删除的数据
- undo log 并非永久保留，事务提交后进入清理阶段，由 purge 线程异步回收空间；innodb_max_purge_lag 可调节清理压力
binlog（归档日志）：主从复制与逻辑恢复的统一接口
binlog 是 MySQL Server 层生成的逻辑日志，记录的是“执行了哪条 SQL”或“某行数据如何变化”，格式可选 STATEMENT（记语句）、ROW（记行变更）或 MIXED。它不依赖存储引擎，所有引擎共用一套 binlog。
- 用于主从复制：主库将 binlog 发送给从库，从库的 IO 线程拉取并存为 relay log，SQL 线程重放执行，实现数据同步
- 支持基于时间点或 GTID 的备份恢复：配合全量备份，可精确恢复到某一时刻状态
- 需手动开启（log_bin=ON），默认不启用；sync_binlog 控制刷盘频率（1 表示每次事务都落盘，最安全但有性能损耗）
其他辅助日志：定位问题与日常运维
除三大核心日志外，MySQL 还提供若干轻量级日志，按需启用即可：
- error log：记录启动、关闭、异常错误、告警信息，默认开启，路径由 log_error 指定，是诊断启动失败或崩溃的第一入口
- slow query log：捕获执行时间超 long_query_time 的语句，配合 log_queries_not_using_indexes 可发现缺失索引的查询，对性能调优至关重要
- general log：记录所有客户端连接与执行的每条 SQL，开启后 I/O 开销大，仅建议临时开启用于复现问题或审计流程
各日志并非孤立运行：一个 UPDATE 事务提交时，InnoDB 先写 undo log 和 redo log，再通知 Server 层写 binlog；两阶段提交（2PC）机制确保 redo log 与 binlog 的一致性，防止主从数据错乱或崩溃后状态不一致。理解这一协作链条，才能真正看懂 MySQL 日志系统的全貌。
