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