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*，找出最后 che
ckpoint 位置
从 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 STATUS\G 的碎片信息。更直接的观测方式：

检查 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、忽略长事务告警），都在悄悄透支数据一致性。

# mysql # 字节 # 为什么 # red # sql # select # 线程 # delete # 异步 # 线上 # 调低 # 的是 # 这是 # 重放 # 就会 # 还没 # 都在 # 最多 # 也能

相关栏目：【网站优化151355 】【网络推广146373 】【网络技术251813 】【 AI营销90571 】