mysql中的事务日志与事务恢复机制

redo log只存物理页变更，如“page 123 offset 48处4字节从0x1234→0x5678”，由ib_logfile0/1组成96MB环形缓冲区；刷盘由innodb_flush_log_at_trx_commit控制：1（每次commit fsync）、0（每秒刷，丢1秒数据）、2（写OS cache后每秒fsync）；崩溃后通过checkpoint起始重放日志前滚恢复已提交事务；undo log存逻辑反向操作，用于回滚和MVCC快照读，由purge线程清理；健康检查需关注log_write_requests/log_writes比值、undo文件大小及长事务。

mysql 事务日志（redo log）到底存什么、怎么刷

redo log 不记录 SQL 语句，只记录「物理页变更」：比如「把 page 123 的 offset 48 处的 4 字节从 0x1234 写成 0x5678」。它由 ib_logfile0 和 ib_logfile1 组成环形缓冲区，默认大小共 96MB（innodb_log_file_size × 2），写满后自动覆盖最旧日志。

关键点在于刷盘时机受 innodb_flush_log_at_trx_commit 控制：

• 1：每次 COMMIT 都强制 fsync 到磁盘（最安全，性能最低）
• 0：每秒刷一次，事务提交时只写入 OS cache（崩溃可能丢一秒数据）
• 2：写入 OS cache 即返回，但每秒 fsync（崩溃最多丢一秒，但比 0 更可靠）

线上生产库强烈建议保持为 1；若压测发现瓶颈，应先查锁/索引，而非盲目调低该值。

为什么 crash 后能用 redo log 恢复未刷盘的脏页

InnoDB 的数据页（buffer pool 中）和磁盘上的页（data file）并不同步。事务提交时，只要 redo log 已落盘，即使 buffer pool 中的修改还没写回 .ibd 文件，崩溃重启后也能靠 redo log「重放」这些变更，让磁盘页追上内存状态。

恢复过程分三步：

• 启动时扫描所有 ib_logfile*，找出最后 checkpoint 位置
• 从 checkpoint 开始顺序读取 redo log，解析出每个物理页修改操作
• 对对应 page 执行「前滚（roll forward）」——即把日志里记的变更再执行一遍

注意：redo log 只负责「事务已提交但数据未写盘」的恢复，不解决「事务未提交就崩溃」的问题——那部分靠 undo log 回滚。

undo log 怎么参与事务回滚与 MVCC

undo log 存在 ibdata1（或独立 undo tablespace）中，记录的是「逻辑反向操作」：比如 INSERT 对应一条 delete，UPDATE 记录旧值以便还原。它有两个核心用途：

• 事务回滚：ROLLBACK 时按 undo log 链逆序执行反向操作
• MVCC 快照读：select 不加锁时，通过 read view + undo log 链找到本事务可见的版本

undo log 不是无限保留的。一旦所有活跃事务（包括长事务）都不再需要某个 undo log 版本，Purge 线程就会异步清理它。如果存在运行数小时的事务，会导致 undo log 膨胀、ibdata1 持续增长，甚至阻塞 purge —— 这是线上慢查询或未关闭连接引发的典型隐患。

如何验证当前 redo/undo 状态是否健康

别只盯着 SHOW ENGINE INNODB STATUSG 的碎片信息。更直接的观测方式：

• 检查 redo 压力：

  SELECT * FROM information_schema.INNODB_METRICS WHERE NAME IN ('log_writes', 'log_write_requests', 'log_padded');

  若 log_write_requests / log_writes 比值长期 > 10，说明日志写入频繁且小包多，可考虑增大 innodb_log_buffer_size

• 看 undo 使用情况：

  SELECT TABLE_NAME, FILE_SIZE, ALLOCATED_SIZE FROM information_schema.FILES WHERE FILE_TYPE = 'UNDO LOG';

  结合 innodb_undo_tablespaces 数量判断是否需收缩

• 揪出危险长事务：

  SELECT trx_id, trx_started, TIME_TO_SEC(NOW() - trx_started) AS duration_sec FROM information_schema.INNODB_TRX ORDER BY duration_sec DESC LIMIT 5;

  超过 60 秒的必须定位来源

事务恢复机制不是黑盒——redo 是前滚引擎，undo 是回滚与快照基石，二者协同才构成 ACID 的物理保障。任何绕过它们的“优化”（如关掉 doublewrite、调低 flush_log_at_trx_commit、忽略长事务告警），都在悄悄透支数据一致性。