MVCC的中文名称是多版本并发控制，它是InnoDB存储引擎为提高事务处理效率而引入的重要机制。多版本的意义在于：当一行数据被多个事务陆续修改，只要这些事务尚未提交，该数据就同时存在多个历史版本。MVCC通过版本链将这些不同时间点的数据状态以指针方式串联起来。
大家好，我是君哥。祝大家国庆节快乐！
MySQL拥有三大核心日志体系：Redo Log、Undo Log和Binlog，其中Undo Log和Redo Log都属于InnoDB存储引擎的特有日志。今天我们就来深入剖析Redo Log与Undo Log的本质区别。
1.Undo Log
1.1 MVCC
多版本并发控制（MVCC）是InnoDB引擎实现高并发事务处理的关键技术。其核心思想是：在事务提交前，每个数据修改都会保留历史快照，形成一条版本链。MVCC的实现机制正是通过版本链将多个数据版本有机串联。
以库存表为例，假设记录商品编号为10的初始库存量为100。当事务一将其修改为98，事务二又将其更新为95。
在事务一修改前，InnoDB会先将stock_count=100的原始记录保存至Undo Log，修改后的版本会保留指向原始Undo Log的指针。同样，事务二在修改前会将事务一修改后的记录（stock_count=98）存入新的Undo Log，并将当前记录指向这个新增的Undo Log记录。这样，对同一行数据的连续修改就构成了版本链，如下图所示：
图片
为实现版本链结构，InnoDB引擎在每行记录中内置了3个隐藏字段：
DB_TRX_ID：记录执行修改（插入、更新或删除）操作的事务ID；DB_ROLL_PTR：回滚指针，即指向上一历史版本的指针，用于实现事务回滚；DB_ROW_ID：当表未定义主键时自动生成的主键，用于创建聚簇索引。1.2 Undo Log
在InnoDB中，事务为保障原子性，需要支持完整的事务回滚操作，这就要求记录数据被修改前的状态（比如插入或删除记录，更新记录值），记录这些修改前状态的日志就是Undo Log。
Undo Log主要承担三大核心功能：
原子性：通过Undo Log实现事务回滚，确保操作原子性；一致性：其他事务在进行一致性读取时，可从Undo Log中获取未被修改的原始数据；MVCC：多版本并发控制中的多个数据版本，正是通过Undo Log记录实现的。Undo Log存储在undo log segments中，而这些段又存放在回滚段（Rollback Segment）。回滚段则分布在undo表空间和全局临时表空间。
图片
回滚段支持的事务数量取决于其能容纳的undo slot数量以及每个事务所需要的undo slot数量。在页面大小为16KB的InnoDB引擎中，每个回滚段可保存1024个undo slot。
每个事务只能使用一个回滚段，但同一个回滚段可以同时服务多个事务。
那么Undo Log何时会被清理呢？需要同时满足两个条件：事务已提交，且Undo Log已过期（即保存时间超过undo retention参数指定的时长）。
当然，即使达到清理条件，也不会立即清除，因为Undo Log所在的回滚段页面可能还被其他未提交事务使用（数据页使用率未达3/4）。
对于insert操作产生的Undo Log，由于只对本事务可见，因此事务提交后即可立即删除。而对于update和delete操作，由于可能涉及MVCC版本链的使用，不能在事务提交后立即清理。
当Undo Log满足删除条件时，会放入待清理队列，等待后台purge线程执行删除。
2.Redo Log
Redo Log同样是InnoDB存储引擎特有的日志，它作为物理日志，记录了在数据页上执行的具体修改操作，主要用于崩溃恢复。
2.1 写日志
在日志写入方面，Redo Log采用循环写入机制，空间大小固定，写满后会覆盖之前的日志记录。
Redo Log采用固定大小的文件组配置，如下图所示配置了4个文件，每个文件大小相同，写满一个后继续写下一个，全部写满后就会清理部分早期日志，继续写入新的日志记录。write pos控制当前写入位置，check point控制可以写入的最后位置，如果两点重合，就需要清理部分日志，让check point向后移动。
图片
2.2 崩溃恢复
Redo Log的核心作用在于崩溃恢复。它确保了数据库宕机后，已提交事务的数据不会丢失。Redo Log基于WAL（预写日志）原则，即先写日志，再写磁盘。事务提交时，先将修改内容记录到Redo Log，MySQL重启后，利用Redo Log进行崩溃恢复。恢复过程如下图：
图片
首先，InnoDB会检查数据页的LSN（日志序列号），并与Redo Log中的LSN进行比对。Redo Log中LSN大于数据页的部分就是需要重做的数据。接着，InnoDB会扫描Redo Log中的待恢复记录，如果日志状态为COMMIT，则直接重做。如果日志状态为PREPARE，还需要检查对应的Binlog，如果该事务的Binlog存在且完整，说明事务已经提交成功，应该重做。如果该事务的Binlog不存在或不完整，说明事务应该回滚，Redo Log记录不需重做。
通过这一机制，确保了Redo Log和Binlog的逻辑一致性：只要Binlog写入成功，数据就一定能够被恢复；如果Binlog没有写入成功，说明事务应该被回滚，数据无需恢复。
3.区别
总结Undo Log与Redo Log的核心区别如下：
最后，我们以下面的SQL为例，来看一下记录日志的完整过程：
update tb_stock set stock_count = 98 where goods_no = 10;
图片
