物理日志和逻辑日志

在 MySQL 的日志系统中,物理日志 和 逻辑日志 是两种不同类型的日志记录方式,它们的设计目标和实现方式有本质区别。以下是它们的详细解释和对比:

1. 物理日志

定义

物理日志记录的是数据页(Page)的物理修改,即直接在磁盘数据页的某个位置写入的具体字节内容。

  • 例如:
    • 修改某表空间第 100 号数据页,偏移量 10 的位置,将值从 0x1234 改为 0x5678
    • 插入一条记录到索引的某个位置,记录其物理位置信息。
特点
  1. 与存储引擎强相关
    • 物理日志直接描述数据页的物理结构,因此与存储引擎的实现紧密绑定(如 InnoDB 的 redo log)。
    • 不同存储引擎的物理日志格式可能完全不同。
  1. 高效恢复
    • 物理日志可以直接将修改应用到数据页,恢复时无需解析 SQL 逻辑,效率极高。
    • 例如:崩溃恢复时,只需按顺序重放 redo log 中的物理修改。
  1. 幂等性
    • 物理日志的操作是幂等的(多次执行结果一致)。例如:无论执行多少次“将页号 100 的偏移量 10 写入值 0x5678”,最终结果都是确定的。
典型应用:Redo Log
  • InnoDB 的 redo log 是物理日志的典型代表,用于保证事务的持久性。
  • 在事务提交时,先将修改的物理日志(redo log)写入磁盘,再异步将脏页刷盘。即使系统崩溃,也能通过 redo log 恢复未刷盘的修改。

2. 逻辑日志(Logical Log)

定义

逻辑日志记录的是操作的逻辑语义,即事务执行的具体操作(如 SQL 语句或反向操作)。

  • 例如:
    • 记录一条反向 SQL:UPDATE users SET name = 'Alice' WHERE id = 1(用于回滚)。
    • 记录一个操作:“删除某条记录,主键为 100”。
特点
  1. 与存储引擎解耦
    • 逻辑日志不依赖底层数据页的物理结构,仅描述操作逻辑,因此可以跨存储引擎使用。
    • 例如:MySQL 的 binlog 是逻辑日志,支持主从复制,无论主库和从库使用何种存储引擎。
  1. 灵活但低效
    • 逻辑日志需要解析操作逻辑,恢复时可能需要重新执行 SQL 或反向操作,效率较低。
    • 例如:回滚事务时,需根据逻辑日志逆向执行 SQL。
  1. 非幂等性
    • 逻辑日志的操作可能不是幂等的。例如:多次执行 UPDATE users SET balance = balance + 100 会导致结果不一致。
典型应用:Undo Log
  • InnoDB 的 undo log 是逻辑日志的典型代表,用于支持事务回滚和 MVCC。
  • 当执行 UPDATEDELETE 时,undo log 会记录反向操作(如旧值或原始 SQL),以便回滚时恢复数据。

3. 物理日志 vs 逻辑日志对比

特性

物理日志(Redo Log)

逻辑日志(Undo Log/Binlog)

记录内容

数据页的物理修改(如字节变化)

操作的逻辑语义(如 SQL 或反向操作)

恢复方式

直接覆盖数据页的物理内容

重新执行 SQL 或反向操作

幂等性

幂等(多次执行结果一致)

非幂等(多次执行结果可能不同)

存储依赖

与存储引擎强相关(如 InnoDB 的 redo log 格式固定)

与存储引擎无关(如 binlog 支持跨引擎复制)

性能

高效(直接操作物理页)

较低(需解析逻辑)

主要用途

崩溃恢复(保证持久性)

事务回滚、MVCC、主从复制(保证原子性、一致性)

4. 为什么需要两种日志?

(1)分工协作
  • Redo Log(物理日志)
    解决崩溃恢复的效率问题,直接重放物理修改,确保数据持久性。
  • Undo Log(逻辑日志)
    解决事务回滚和 MVCC 的灵活性需求,记录逻辑操作,支持多版本数据读取。
(2)性能与灵活性的平衡
  • 物理日志的高效性适合高频写入场景(如事务提交时的快速刷盘)。
  • 逻辑日志的灵活性适合跨事务、跨引擎的协作(如主从复制或一致性读)。
(3)事务的 ACID 保障
  • Redo Log:确保已提交事务的修改不丢失
  • Undo Log:确保未提交事务的修改可回滚,并为读操作提供多版本数据

5. 实际场景示例

场景 1:事务提交与崩溃恢复
  1. 事务提交时:
    • 先写 undo log(逻辑日志,记录旧值)。
    • 再写 redo log(物理日志,记录新值到数据页)。
  1. 系统崩溃后:
    • 通过 redo log 重放所有已提交事务的物理修改。
    • 通过 undo log 回滚未提交事务的逻辑操作。
场景 2:MVCC 实现
  • 事务 A 查询数据时,若该数据被事务 B 修改但未提交:
    • InnoDB 通过 undo log(逻辑日志)找到旧版本数据返回给事务 A。
    • redo log 不参与此过程,因为它仅负责物理恢复。

6. 总结

  • 物理日志是“物理层”的记录,直接操作数据页的字节内容,高效但缺乏跨引擎兼容性。
  • 逻辑日志是“逻辑层”的记录,描述操作语义,灵活但性能较低。
  • Redo Log 和 Undo Log 的协作
    • Redo Log 确保数据不丢失(持久性)。
    • Undo Log 确保事务可回滚(原子性)和读一致性(隔离性)。
  • 两者的结合,使得 MySQL 在保证事务 ACID 特性的同时,兼顾性能和灵活性。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值