MySQL是原地更新记录的，事务的更新是直接作用到旧有记录，旧有记录被写到undo。同时，它又是steal的，意味着未提交的数据可以被持久化。undo有两个作用，名列前茅，必须要有办法找回旧记录以回滚事务。
一、mysql为什么需要undo log
MySQL是原地更新记录的，事务的更新是直接作用到旧有记录，旧有记录被写到undo。同时，它又是steal的，意味着未提交的数据可以被持久化。undo有两个作用，名列前茅，必须要有办法找回旧记录以回滚事务。同时，需要保存旧记录实现多版本。
当然，没有undo的数据库也有，比如PostgreSQL。它不会原地更新，更新就是插入一个新版本。当然，这样做的代价是浪费空间，失效记录太多了就会影响效率，需要定期的垃圾回收。
在InnoDB中，有三种日志跟事务的ACID关系都很大：
- undo log负责原子性，保护事务在exception或手动rollback时可以回滚到历史版本数据
- redo log负责落盘式持久性，保证事务提交后新的数据不会丢失
- binlog负责副本式持久性，可以将主节点上的数据复制到从节点，主节点crash后业务可以正常运转
可以看到，undo log只关心过去，redo log只关心未来
如果我们只记录一个历史版本数据，其它事务每次都只需要读取到最新版本的数据，的确是这样，这个就是Read Committed
但是，如果说你要备份整个数据库，整个事务可能会持续一个小时，同时有大量线上并发修改操作，我相信你一定希望读取到逻辑一致的数据。这时同一行数据就需要支持多个历史版本的数据了，这一招叫MVCC，对应Repeatable Read隔离级别，而记录多个历史版本数据的地方就叫undo log
实践中，对于面向个人业务的互联网在线业务，推荐Read Committed；对于分析性业务，推荐Repeatable Read（InnoDB的默认事务隔离级别）
InnoDB将undo log作为数据的一部分存储到了redo log中，因此很多时候不太区分它们。
延伸阅读：
二、undo log的工作原理
在更新数据之前，MySQL会提前生成undo log日志，当事务提交的时候，并不会立即删除undo log，因为后面可能需要进行回滚操作，要执行回滚（rollback）操作时，从缓存中读取数据。undo log日志的删除是通过通过后台purge线程进行回收处理的。
1、事务A执行update操作，此时事务还没提交，会将数据进行备份到对应的undo buffer，然后由undo buffer持久化到磁盘中的undo log文件中，此时undo log保存了未提交之前的操作日志，接着将操作的数据，也就是Teacher表的数据持久保存到InnoDB的数据文件IBD。
2、此时事务B进行查询操作，直接从undo buffer缓存中进行读取，这时事务A还没提交事务，如果要回滚（rollback）事务，是不读磁盘的，先直接从undo buffer缓存读取。
