【MySQL】第8节|Innodb底层原理与Mysql日志机制深入剖析(一)

发布于:2025-05-25 ⋅ 阅读:(23) ⋅ 点赞:(0)

MySQL 的 redo log(重做日志)

redo log 是 MySQL 中 InnoDB 存储引擎实现事务持久性的关键机制,用于记录数据库数据的变更,确保事务提交后数据不丢失,即使发生宕机也能通过日志恢复数据。

核心作用

1. 实现事务的持久性(Durability)

事务提交时,先将变更记录写入 redo log 并持久化到磁盘,再执行实际的数据页更新(可能延迟执行,即 WAL 机制,Write-Ahead Logging)。

    • 即使数据库崩溃,重启后可通过 redo log 恢复未写入数据页的变更,保证事务提交的结果不丢失。

2. 提升写入性能

数据页更新可能需要随机 IO(较慢),而 redo log 按顺序写入磁盘(顺序 IO,速度快),避免频繁直接操作数据页,提升事务提交效率。

关键概念

redo log 组成

  • 重做日志文件(物理文件,如 ib_logfile0ib_logfile1):

固定大小、循环写入(类似环形缓冲区),默认大小约 48MB(可通过 innodb_log_file_size 配置)。

  • 重做日志缓冲redo log buffer,内存区域):

事务执行过程中,变更先写入内存缓冲,提交时刷新到磁盘日志文件。

WAL 机制(Write-Ahead Logging)

事务提交时,先写 redo log 到磁盘,再更新数据页(可能延迟到 checkpoint 时执行)。

    • 示例:

执行 UPDATE user SET age=20 WHERE id=1 时:

  • 生成 redo log 记录(记录“id=1 的行,age 从 18 变为 20”)。
  • 将 redo log 写入内存缓冲。
  • 事务提交时,将缓冲中的 redo log 刷新到磁盘日志文件(此时事务已提交,数据不丢失)。
  • 数据页更新可能在后续由后台线程执行(buffer pool 刷新)。

重要参数

参数名

说明

innodb_log_file_size

单个 redo log 文件大小,影响写入性能和恢复速度(增大可减少切换频率,但恢复时间更长)。

innodb_log_files_in_group

日志文件数量,默认 2 个(ib_logfile0 和 ib_logfile1)。

innodb_flush_log_at_trx_commit

控制 redo log 刷新到磁盘的时机(0/1/2,默认 1,保证事务持久性)。

与崩溃恢复的关系

当数据库宕机重启时,InnoDB 会执行以下步骤:

  1. 重做(Redo):扫描 redo log,将已提交但未写入数据页的变更应用到数据页。
  2. 回滚(Undo):利用 undo log 回滚未提交的事务(由事务原子性保证)。
    • 示例:若事务 T 提交后 redo log 已写入磁盘,但数据页未更新时宕机,重启后通过 redo log 完成数据页更新,确保 T 的变更生效。

总结

redo log 是 InnoDB 实现事务持久化的核心机制,通过 顺序写日志+延迟更新数据页 的方式提升性能,同时保证数据不丢失。理解 redo log 有助于优化事务性能(如调整 innodb_flush_log_at_trx_commit)和诊断故障(如日志文件大小设置不合理导致频繁切换)。


网站公告

今日签到

点亮在社区的每一天
去签到