几年前我第一次被分到数据库运维岗，带我的师傅上来就扔给我一句话：“你去把MySQL的redo日志搞清楚，搞不懂它，你以后排障就是瞎猜。”当时我还不服气，后来真正遇到一次机房断电，几百个业务库重启后全靠redo日志做崩溃恢复，我才明白这东西才是InnoDB最硬的底牌。今天就把我这几年的理解和踩坑记录整理出来，专门讲讲MySQL生成的redo记录到底是什么、它怎么工作、怎么配置、出问题怎么排查。
先说结论：redo日志是InnoDB存储引擎为了支持崩溃恢复而写的一组重做记录，它把“数据页将要被怎么修改”这件事提前落盘。数据库突然断电、进程被kill、服务器重启，只要redo日志还在，InnoDB就能在重启后把数据恢复到崩溃前的那一刻。如果你从来没认真看过redo日志，那你对MySQL“数据不丢”这四个字的信任，其实是建立在一个黑盒上的。
1. 重新认识InnoDB的“先写日志”机制
1.1 为什么不能直接改数据文件
很多刚接触MySQL的人会有一个朴素疑问：既然要改数据，直接把磁盘上对应的数据页改了不就行了，为什么还要绕一圈先写日志？
问题出在性能上。数据库的读写单位是页，默认16KB。你执行一条update语句可能只改了其中几个字节，但如果要把整个16KB的页写回磁盘，一次随机IO的成本非常高。更麻烦的是，一次事务可能要修改多个页，这些页在磁盘上的位置分散，意味着多次随机写。如果每次都边改边刷盘，数据库的TPS会被磁盘IO拖垮。
InnoDB想到了一个折中方案：内存里维护一块缓冲池（Buffer Pool），数据页先在内存里修改，形成一个“脏页”，脏页积累到一定程度再批量刷回磁盘。这个概念听起来很美好，但立刻引出一个致命问题：如果脏页还没来得及刷盘，机器突然断电了，内存里的修改就全没了，数据不就丢了吗？
1.2 Redo日志就是那本金字塔账本
为了解决“内存改了但磁盘没改”的窗口期风险，InnoDB采用了经典的Write-Ahead Logging（WAL）策略，中文叫预写日志。核心规则只有一条：数据页在刷盘之前，对应的修改记录必须先写入redo日志并完成落盘。
打个比方，这就像你开了一家店，每天的流水太多，来不及逐笔记到正式账本里，就先撕张纸条记下“今天卖了什么东西、收了多少钱”，然后把纸条锁进保险箱。晚上或者第二天，再根据纸条誊抄到正式账本。如果突然停电，正式账本还没誊完，没关系，打开保险箱看纸条就能把账补上。这个保险箱，就是redo日志。
所以redo日志的本质，是一份记录了“数据页将要发生什么变化”的流水账。它不保存完整的数据页，只保存变化本身。因为只记录变化，它的写入量比整个数据页小得多，而且写redo日志是顺序追加，顺序IO比随机IO快一个数量级，性能优势非常明显。
1.3 崩溃恢复到底做了什么
当MySQL异常崩溃后重新启动，InnoDB会进入恢复流程。它会扫描redo日志，找到最近一次成功刷盘的检查点（Checkpoint），然后把检查点之后的日志一条一条取出来，重新在对应的数据页上执行一遍修改。这个过程叫做前滚（Roll Forward）。
所以严格来说，redo日志解决的是“已提交但尚未刷脏页”的数据丢失问题和“修改了一部分但还没提交”的脏数据回滚问题。对于未提交的事务，恢复时还要结合undo日志进行回滚，这里先不展开，后面单独说。
2. redo日志的物理存储与内部推进机制
2.1 文件长什么样、放在哪里
MySQL 8.0.30之前的版本，redo日志默认是ib_logfile0、ib_logfile1这样的文件，放在数据目录下。从8.0.30开始，文件改名为#ib_redo0、#ib_redo1这种带井号前缀的形式，仍然在数据目录的#innodb_redo子目录里。改名不是因为闲得慌，而是为了支持redo日志文件的动态调整和更灵活的内存管理，这个后面再说。
日志文件是固定大小、循环写入的。什么是循环写入？你可以想象成一根环形跑道，日志从起点开始写，写满一圈后再回到起点覆盖旧内容。关键是，InnoDB不会盲目覆盖，它必须保证待覆盖的日志对应的数据页都已经安全刷入磁盘了，否则一旦覆盖，旧的修改记录就彻底丢了，崩溃时无法恢复。
2.2 LSN：贯穿始终的指针
谈到redo日志，绕不开一个概念：LSN（Log Sequence Number，日志序列号）。你可以把它理解成日志文件里的“字节级坐标”。每写一条redo记录，LSN就会增加对应字节数。整个InnoDB内部到处都在用LSN做对账：
- 数据页上记录着一个
page_lsn，表示这个页最近一次被修改时对应的LSN位置。 - 缓冲池里的脏页链表按照LSN排序，刷盘时按顺序刷。
- 检查点其实就是一个LSN值，表示这个位置之前的日志都已经被数据页“吸收”了。
恢复的时候，InnoDB从最近的检查点LSN开始扫描redo日志，找到需要恢复的页，重放后续所有修改。所以LSN不仅是一个数字，它像一根线把redo日志、缓冲池、数据页、检查点串成了一个体系。
2.3 日志缓冲与组提交
redo日志也不是每产生一条就立刻写磁盘，那样太慢了。它先写到内存里的log buffer（日志缓冲区），由后台线程或者事务提交时触发刷盘。刷盘条件主要由参数innodb_flush_log_at_trx_commit控制：
- 值为0：事务提交时不主动刷盘，每秒刷一次。性能最好，但MySQL进程崩溃可能丢失最近1秒内的事务。
- 值为1：每次事务提交都把redo日志刷到磁盘。最安全，性能开销最大。
- 值为2：事务提交时把日志写入操作系统缓存，每秒再真正落盘。MySQL进程崩溃不会丢，但操作系统宕机会丢最近1秒的数据。
生产环境我几乎一律设成1。这个参数是数据安全与性能之间最直接的取舍点，千万不要为了追求性能盲目改成0，一旦出现故障，损失可能是几十万条业务记录。
再说组提交（Group Commit）。当多个事务同时进入提交阶段，它们可以共享同一次刷盘操作。也就是说，一组事务的redo日志一次性写进磁盘，而不是一个事务刷一次。这个机制极大提升了高并发下的提交效率。MySQL在5.7之后对组提交做了大量优化，这也是为什么在高并发场景下，把sync_binlog和redo刷盘都设成严格模式，性能损失比早期版本小很多。
2.4 检查点是如何推进的
检查点机制值得单独拿出来说。InnoDB的后台线程会持续把脏页刷入磁盘，每刷完一批脏页，检查点LSN就能向前推进。你可以通过SHOW ENGINE INNODB STATUS看到当前日志序列号和最近检查点的位置。
如果脏页刷得太慢，redo日志文件眼看要被写满循环回来了，InnoDB会强制加速刷脏页。这就是有时候你会看到磁盘IO突然飙升的原因之一。如果刷脏页的速度长期跟不上写入速度，日志文件写满后，MySQL会报错“log file is full”甚至阻塞事务写入，这时候必须介入处理，而不是干等着。
3. redo记录里到底装了什么
3.1 一条redo记录的内部结构
很多人误以为redo日志记录的是完整的SQL语句，这也是个常见误区。redo里面不是SQL，而是物理变化描述。一条redo记录通常包含：日志类型、表空间ID、页号、在页内的偏移量、修改的长度、修改前后的数据内容等。
为什么记这些而不记SQL？如果记录SQL，恢复时要重新解析SQL、重新执行一遍，效率太低，而且同一个SQL在不同时间点执行结果未必相同，不具备“重放”的确定性。redo只操作“哪个页的哪个位置变成了什么”，直接定位到字节级别，恢复时不需要任何逻辑判断，只按照记录把数据页改回去，速度极快。
从另一个角度说，redo是物理日志，记录页的物理变化；binlog是逻辑日志，记录SQL语句或者行级别的逻辑变化。这也是两者最大的区别之一。
3.2 哪些操作会触发redo的写入
只要涉及数据页的修改，就会写redo。典型场景包括：
- INSERT、UPDATE、DELETE导致的聚簇索引页和二级索引页变化。
- 某些DDL操作，比如重建表过程中对数据页的修改。
- 内部系统操作，比如分配新的段、更新系统页、修改数据字典等。
读操作不产生redo，只修改内存不修改磁盘的操作也不写redo。所以纯SELECT压力再大，也不会把redo日志撑爆。
3.3 redo和binlog的分工差异
这个问题几乎每次面试都会遇到，我也在实际排障中吃过没分清二者亏。
redo日志是InnoDB存储引擎层的，服务于崩溃恢复，解决的是“数据文件没写全，重启后怎么补全”的问题。binlog是MySQL Server层的，服务于主从复制、时间点恢复，解决的是“数据库历史状态如何重现”的问题。
举一个最简单的对比：如果你在主库执行一条UPDATE操作，binlog会被主库发给从库，让从库也做同样的变更；而redo日志只在单机上用于本机崩溃恢复，主库和从库各自写各自的redo，从不互相传递。
还有一个经典问题：为什么要有两份日志？因为在InnoDB刚被集成到MySQL的那个年代，MySQL自己已经有binlog了，但binlog是逻辑日志，不能用来做存储引擎底层的崩溃恢复。InnoDB为了保证自身数据文件的物理一致性，必须在引擎层维护一套物理日志。为了确保binlog和redo日志的一致性，MySQL引入了内部XA机制，两阶段提交：先写redo并处于prepare状态，再写binlog，最后提交事务并更新redo状态。这套机制保证了两个日志不会出现“一边有一边没有”的断层。
4. 这些参数直接影响redo的行为
4.1 redo日志容量怎么定
从8.0.30开始，可以通过innodb_redo_log_capacity直接设置所有redo日志文件的总体容量，默认值是104857600字节，也就是100MB。这个参数替代了老版本里innodb_log_file_size和innodb_log_files_in_group的组合配置。在8.0.30之前，你需要分别配置单个日志文件大小和文件个数，总容量等于两者相乘。
设置容量的核心思路是：让redo日志能够覆盖一次“刷盘高峰周期”。如果日志容量太小，遇到大量写入时，日志很快就到循环覆盖的边缘，InnoDB会被迫疯狂刷脏页，磁盘IO飙升，写入吞吐量急剧下降。容量太大也有问题，崩溃恢复时要扫描更多日志，恢复时间变长。
具体设多大？我一般这样估算：先去业务高峰时段观察SHOW ENGINE INNODB STATUS里的每秒产生日志量（Log sequence number的增长速度），再用日志总量除以每秒产生量，确保容量能覆盖5到10分钟的高峰写入量。对于纯OLTP业务，512MB到2GB是比较常见的区间；写入密集型的批处理任务，可能需要8GB以上。建议你设置后持续观察一两周，再结合“日志写入量 vs 脏页刷出量”的曲线做调整。
4.2 刷盘粒度相关的参数
还有一个参数叫innodb_log_buffer_size，默认16MB，它控制log buffer的大小。如果单个大事务产生大量redo记录，日志缓冲区不够用，会提前触发写入磁盘，性能可能波动。对于有大事务、批量导入的场景，适当调大到64MB或128MB往往有立竿见影的效果。需要说明的是，这不是说越大越好，超过实际需求只会白白占用内存。
另外还有一个容易被忽视的参数：innodb_log_write_ahead_size，默认8192字节。它控制预写粒度，目的是避免“写半个块”导致的额外IO。如果你发现redo文件写入IOPS异常高，可以关注一下这个值是否和操作系统块大小匹配。大多数情况默认即可，不必过分调整。
4.3 监控redo最有效的几个命令
很多人上来就查SHOW VARIABLES LIKE 'innodb_log%'，其实这只是看配置，真正要看状态，需要用命令SHOW ENGINE INNODB STATUS。在这个输出里，有一段LOG信息，核心字段包括：
- Log sequence number：当前写到哪了。
- Log flushed up to：日志刷到磁盘的位置。
- Last checkpoint at：最近检查点位置。
- Log file capacity：日志总量。
- Pending log writes：等待写入的日志请求数。
如果Log sequence number和Log flushed up to之间差距长期很大，说明日志在log buffer里积压，刷盘可能成了瓶颈。如果Last checkpoint at和当前LSN差距持续扩大，说明脏页刷得太慢，时间一长就可能触发日志满导致阻塞。
MySQL 8.0还提供了performance_schema里的log_status等表，可以查看更细粒度的日志状态。日常巡检我习惯写一个脚本，每隔5分钟采集一次这几个LSN差值，一旦指标异常就触发告警。
5. 实际运维中的常见问题与排查实录
5.1 “log file is full”类问题的实际处理
有一次我接到告警，线上一个核心库的事务提交变得极慢，报错信息里有“log file is full”相关字眼。查了一下状态，发现这个库的redo日志容量只设了256MB，业务却在跑一个大批量更新任务，每秒产生的日志量超过10MB，不到半分钟就把日志文件写满了。由于刷脏页跟不上，InnoDB只能把写入速度压下来等刷盘，事务自然就卡住了。
处理思路分三步：第一步，紧急情况下扩容redo日志容量，MySQL 8.0.30之后可以通过SET GLOBAL innodb_redo_log_capacity = 4294967296在线调整，这在新版本里是个很好的优势；第二步，检查Buffer Pool大小和刷脏页策略，如果脏页比例长期偏高，考虑适当调大innodb_buffer_pool_size，或者调整innodb_io_capacity让后台刷脏页更积极；第三步，把大事务拆成小批提交，避免短时间内日志生成量过于集中。
5.2 redo日志文件磁盘空间告警
redo日志文件是固定大小循环复用的，理论上不会自己无限膨胀。但8.0.30之后的版本，#innodb_redo目录里的文件会动态变更编号，如果启用innodb_redo_log_capacity的同时出现目录里文件数量非常多的情况，一般正常，但如果你看到磁盘占用异常增长，要检查是不是有文件残留没有被清理。
遇到过一种情况：双实例共用同一数据目录，或者数据目录被错误地做了快照恢复，导致redo日志文件和数据文件状态不匹配，InnoDB启动时始终找不到一致的检查点，恢复过程反复回放同一个位置。这种问题别想着手工删redo文件，只要redo文件缺失，MySQL基本无法安全启动。正确做法是把整个数据目录恢复到备份一致性的状态，再正常启动。
5.3 redo相关性能瓶颈的定位
如果你的数据库明显变慢，怀疑redo写入是瓶颈，可以从三个维度定位。
先跑SHOW ENGINE INNODB STATUS看Log sequence number和Log flushed up to的差距。如果差距保持在几十MB以上，再看Last checkpoint at离当前LSN有多远。如果检查点位置明显落后，说明瓶颈在刷脏页，而不在redo写入本身。这时候要调整的不是日志容量，而是刷脏页的速率：检查innodb_max_dirty_pages_pct、innodb_io_capacity等参数，也可以观察是否有全表扫描后产生大量脏页的SQL在背后捣乱。
如果LSN推进本身很慢，那问题可能出在磁盘顺序写能力上。SSD和普通机械盘在顺序写上的差距非常明显，redo日志对顺序写性能极其敏感。碰上云主机里共享磁盘IO被其他虚拟机挤占的情况，redo写入延迟会成倍上升。我遇到过一次，排查半天发现是同一块云盘上另一个实例在跑全量备份，IO被打满，redo日志刷盘从几毫秒涨到几百毫秒，整个业务写入全部被拖垮。
5.4 关于redo日志容量调整的一个提醒
修改redo容量在8.0.30之前有一个很折腾的限制：必须把innodb_fast_shutdown设为0，然后正常关闭MySQL，删除旧的ib_logfile*，修改配置文件后再启动。这套操作在版本升级、数据量很大的环境里有风险，操作不当可能导致启动失败。所以升级到8.0.30及以上版本，能用innodb_redo_log_capacity动态调整就尽量用动态方案，别再去玩删除日志文件的老操作了。
另外，生产环境的配置变更一定先在测试环境跑一遍全流程，尤其注意备份数据的可恢复性。我见过因为调整redo容量后没有做完整重启验证，结果业务高峰期实例启动失败，恢复到备份时才发现备份时间点太久，数据损失了一个小时。这个教训相当惨痛。
5.5 崩溃恢复时间过长怎么处理
如果你发现MySQL异常重启后，恢复阶段花了很长时间才进入正常服务状态，多半是redo日志过大或者检查点太旧。检查点太旧意味着从上次检查点到日志末尾之间积累了大量需要回放的修改，恢复时就要一条一条重放。
缓解办法：定期制造检查点。MySQL后台刷脏页线程本身就在推进检查点，但在低写入量时段，可以手动执行FLUSH LOGS或者SET GLOBAL innodb_max_dirty_pages_pct = 0触发更激进的脏页刷盘。日常运维中，我更推荐关注监控曲线，如果发现检查点长期不推进，就要考虑是不是刷脏线程被卡住，或者redo容量设得过大导致检查点推进不再迫切，从而失去了自我调节的动力。
崩溃恢复本身还有一个常见误区：以为redo日志越大越安全。其实安全度取决于最近一次检查点距离当前日志末尾的差距，日志总量大并不天然等于恢复时间长，但如果日志大多而检查点长期保持非常旧，恢复时间和启动时间都会明显变长。
6. 再聊点实战中的心得
最后说几个个人体会，不一定都在文档里。
第一，redo日志的真实速度不体现在“日志生成了多少”，而体现在“日志刷下去多快”。排查写入慢的时候，先分清是生成慢还是落盘慢，方向错了会白白浪费很多时间。第二，事务提交参数innodb_flush_log_at_trx_commit不要轻易设成0，很多公司开发环境图快改了配置，结果把类似问题带到线上，出了事故才想起来查这个参数。第三，做备份恢复演练时，不要只验证数据完整性，记得观察重启后的恢复时间和redo日志状态，有时候恢复时间比数据本身更能说明系统的健康状况。
还有一个非常容易被忽略的细节：undo日志和redo日志经常被混为一谈。redo负责重做，undo负责回滚，它们配合才能保证事务的原子性和持久性。一个直观的记忆方法是：redo说“做了的事要留下痕迹”，undo说“没做完的事要能撤销”。排查问题的时候如果把这两个概念搞混，很容易把崩损恢复的分析方向带偏。
MySQL里面真正决定数据不丢的，不是那句“我提交成功了”，而是redo日志已经安全落盘的那一下。理解了这一点，再看很多数据库行为，就会有一种豁然开朗的感觉。希望这篇文章能帮你在自己的MySQL排障路上少走一些弯路。
