MySQL面试题事务实现全解析：Undo Log、Redo Log、锁与 MVCC 协同机制详解

MySQL有四大特性分别是原子性、一致性、持久性、隔离性。

MySQL实现事务靠Undo log、Redo log、锁、MVCC这四个核心组件来实现的

通过Undo log来实现原子性,在进行写操作之前，会把原来的数据存入Undo log中，当事务回滚时，通过Undo log进行反向操作，把数据恢复回去。
通过Redo log 来实现持久性，在进行写操作时，不会直接把数据写入磁盘数据页，而是先写入Redo log，就算写入磁盘数据页宕机了，也能通过重做Redo log来恢复数据。
通过锁机制来实现写的隔离性，当两个事务同时改一个数据时，必须一个等另一个释放锁，InnoDB支持行锁，间隙锁防止幻读。
通过MVCC来实现读写的隔离性，读的时候不加锁，而是通过Undo log版本链来找到自己读的数据版本，读的时候能写，写的时候也能读。

InnoDB在写入数据时，不会直接把数据写入磁盘的数据页，因为这样做随机磁盘IO太多，性能不好，而是先把数据顺序写入Redo log中，再找时间把数据页刷到磁盘上，应为顺序写比随机写快。
redo log是通过循环写来实现的，redo log中有两个指针，一个记录写到哪里了，一个记录刷盘刷到哪里了，两指针之间就是待刷盘的脏数据。
事务提交时，redo log必须落盘，这个行为由 innodb_flush_log_at_trx_commit 控制：
- 设置成1，每次提交都要刷盘
- 设置成0，每一秒刷一次盘，宕机可能造成一秒的数据丢失
- 设置成2，把数据写到系统缓存中，MySQL宕机不丢失，服务器挂了才丢。

InnoDB和Server层各有自己的日志，redo log 和bin log，为了保证两个日志的一致性，所以用到了两个阶段。

准备阶段：redo log写盘，然后把状态改为prepare
提交阶段：bin log写盘，然后redo log状态改为commit
如果是bin log写入前宕机，redo log的状态为prepare，但是没有对应的bin log，则触发回滚
如果是bin log写入后宕机，redo log的状态为prepare，有对对应的bin log，则会触发事务提交
这一套机制保护了主从复制的数据一致性，主表靠redo log数据恢复，从表靠bin log数据同步。

InnoDB的行锁是加在索引上的，如果修改数据时没有走索引，就会锁住整张表

InnoDB有三种行锁：

MVCC是多版本并发控制，核心思想是让读写互不阻塞：写操作会产生新的版本，读操作会根据事务的ReadView在Undo log的版本链上找到自己版本的数据。

MySQL 有三种核心日志。bin log 负责主从复制和数据恢复，redo log 保证崩溃后数据不丢，undo log 支撑事务回滚和 MVCC。

bin log 是 Server 层的日志，记录的是逻辑操作，也就是原始 SQL 或者行变更前后的值。它的核心场景是主从同步，从库拉取主库的 bin log 重放一遍就能保持数据一致。另外做数据恢复的时候，也是靠 bin log 配合全量备份回放到指定时间点。
redo log 是 InnoDB 引擎独有的，记录的是物理变更，具体就是"某个数据页的某个偏移量改成了什么值"。它的作用是 MySQL 挂了重启后，InnoDB 会用 redo log 把没来得及刷盘的脏页恢复出来。redo log 是循环写的，空间固定，写满了就得等 checkpoint 推进才能继续。
undo log 也是 InnoDB 的，记录的是数据修改前的旧值。事务回滚的时候，就靠 undo log 把数据改回去。另外 MVCC 的快照读也依赖它，别的事务要读历史版本，顺着 undo log 链往前找就行。

MySQL面试题 事务实现全解析：Undo Log、Redo Log、锁与 MVCC 协同机制详解