Redo Log 是 InnoDB 崩溃后数据不丢的唯一依据，记录页号、偏移量等物理变更而非 SQL 语句，通过 LSN 对齐实现快速重做恢复，其安全性取决于事务提交时是否已落盘。
Redo Log 不是“可选配件”，而是 InnoDB 崩溃后数据不丢的唯一依据——没有它，事务提交就等于没发生。
Redo Log 是物理日志，不是 SQL 记录
它不记录 UPDATE user SET name='test' 这类语句，而是记录「页号、偏移量、修改前值、修改后值」这样的物理变更。比如：page_id=100, offset=200, old=0x12, new=0x34。这种格式让崩溃恢复时无需解析 SQL、无需执行逻辑判断，直接覆写内存页即可，速度极快。
常见错误现象：误以为开启 binlog 就能替代 redo log —— 实际上 binlog 是逻辑日志、server 层日志，且默认异步刷盘；而 redo log 是引擎层物理日志，强制顺序写入磁盘文件 ib_logfile0 和 ib_logfile1，两者不可互换。
崩溃恢复依赖 LSN 对齐，不是靠“重放时间”
每个数据页头部存有 page_lsn，表示该页最后一次刷盘时对应的日志位置；redo log 文件尾部维护全局 log_lsn。重启时 InnoDB 只重做那些 page_lsn < log_lsn 的页——也就是还没刷进磁盘的脏页。
- 如果
innodb_flush_log_at_trx_commit = 0，事务提交后日志只写入内存log_buffer，断电即丢，最多丢失 1 秒数据 - 如果设为
1（默认），每次提交都调用fsync()落盘，确保日志已持久化到ib_logfile* - 设为
2时仅fdatasync()到 OS 缓存，依赖操作系统不崩溃，但主机断电仍可能丢日志
Redo Log 文件大小和数量直接影响恢复时间和写入吞吐
默认两个文件 ib_logfile0 和 ib_logfile1，构成环形缓冲。大小由 innodb_log_file_size 控制，太小会导致频繁 checkpoint 和日志切换，拖慢写入；太大则崩溃后重放耗时增加（因为要扫描更多日志）。
调整需谨慎：innodb_log_file_size 修改必须停库，且新旧文件大小不一致时 MySQL 启动会拒绝加载。验证方式很简单：
ls -lh /var/lib/mysql/ib_logfile*
看到两个固定大小、权限为 -rw------- 的文件，才是正常落盘状态。
真正容易被忽略的是：Redo Log 的安全性不取决于“有没有”，而取决于“是否在事务提交那一刻已落盘”。哪怕配置再大、文件再多，只要 innodb_flush_log_at_trx_commit 不是 1，或磁盘未启用 write cache 禁用（hdparm -W0 /dev/sdX），就存在丢数据风险。
