MySQL日志详解

MySQL日志系统是保障数据一致性与故障恢复的核心机制！本文将深入解析undo log（实现事务回滚与MVCC）、redo log（确保崩溃恢复）和binlog（主从同步）三大关键日志重点剖析两阶段提交如何协调binlog与redo log的原子性，详解undo log通过DB_ROLL_PTR链式存储历史版本，以及MVCC如何结合DB_TRX_ID与Read View实现读写并发同时对比日志刷盘策略（innodb_flush_log_at_trx_commit vs sync_binlog），揭示InnoDB事务持久化的底层设计 。

MySQL日志详解

• 日志分类与重要性
  • MySQL日志类型
    • 错误日志、查询日志、慢查询日志、事务日志、二进制日志
  • 重要日志类型
    • 二进制日志binlog、事务日志redo log与undo log
• redo log（重做日志）
  • redo log作用
    • 提供MySQL崩溃恢复能力
  • redo log工作机制
    • 数据以页为单位，查询与更新先操作Buffer Pool
    • 修改记录在redo log buffer，后刷盘到redo log文件
  • redo log记录内容
    • 表空间号+数据页号+偏移量+修改数据长度+具体修改的数据
  • 刷盘时机与策略
    • 事务提交、log buffer空间不足、事务日志缓冲区满、Checkpoint、后台刷新线程、正常关闭服务器
  • 刷盘策略innodb_flush_log_at_trx_commit
    • 值为0：事务提交不刷盘，可能丢失1秒内事务
    • 值为1：事务提交刷盘，保证数据不丢失
    • 值为2：事务提交写入page cache，宕机可能丢失1秒内事务
  • 日志文件组与环形数组
    • write pos与checkpoint属性
    • MySQL 8.0.30前配置：innodb_log_files_in_group与innodb_log_file_size
    • MySQL 8.0.30后配置：innodb_redo_log_capacity
    • 日志文件类型：ordinary与spare
  • redo log与数据页刷盘对比
    • redo log记录修改内容，顺序写，性能高
    • 数据页刷盘完整数据页，随机写，性能差
• binlog（归档日志）
  • binlog作用
    • 数据备份、主备、主主、主从同步，保证数据一致性
  • binlog记录格式
    • statement：记录SQL语句原文
    • row：记录操作具体数据，保证数据一致性
    • mixed：statement与row混合，根据SQL语句判断
  • binlog写入机制
    • 事务执行中写入binlog cache，事务提交写入binlog文件
    • binlog_cache_size参数控制单个线程binlog cache大小
  • binlog刷盘流程与参数sync_binlog
    • 值为0：提交事务只write，系统判断fsync时机
    • 值为1：提交事务执行fsync，保证数据不丢失
    • 值为NN>1：提交事务write，累积N个事务后fsync
• 两阶段提交与日志一致性
  • 两阶段提交原理
    • redo log写入拆分为prepare与commit两个步骤
  • 两阶段提交解决日志不一致问题
    • 写入binlog异常：redo log处于prepare阶段，无binlog日志，回滚事务
    • redo log commit阶段异常：找到对应binlog日志，提交事务恢复数据
• undo log（回滚日志）
  • undo log作用
    • 事务回滚，恢复数据到事务开始前状态
  • undo log记录内容
    • 逻辑日志，记录SQL语句，如DELETE对应INSERT
  • undo log持久性与清理
    • undo log信息记录到redo log中，实现持久性保护
    • INSERT操作事务提交后清除，UPDATE/DELETE操作加入history list，由purge线程清理
  • undo log记录方式与管理
    • 采用segment方式记录，每个undo操作占用一个undo log segment
    • 事务开始时分配rollback segment，包含1024个undo log segment
    • rollback segment header管理rollback segment，history list记录已提交未清理事务的undo log
  • MVCC实现与undo log关系
    • MVCC依赖隐藏字段、Read View、undo log
    • InnoDB通过DB_TRX_ID与Read View判断数据可见性
    • 不可见时通过DB_ROLL_PTR找到undo log历史版本