MTR全称是Mini-Transaction，顾名思义，可以理解为"最小的事务"，MySQL中把对底层页面的一次原子访问的过程称之为一个Mini-Transaction，这里的原子操作，指的是要么全部成功，要么全部失败，不存在中间状态。
MTR主要是被用在写undo log和redo log的场景下的。例如，我们要向一个B+树索引中插入一条记录，此时要么插入成功，要么插入失败，这个过程就可以称为一个MTR过程，这个过程中会产生一组redo log日志，这组日志在做MySQL的崩溃恢复的时候，是一个不可分割的整体。
假如我们有一个事务，事务中包含3条语句，那么MTR的概念图如下：
Mini-Transaction一般遵循三条原则：
1、the fix rules
2、WAL
3、force-log-at-commit
这里我们解释下这三条原则：
1、the fix rules
解释第一条规则之前，我们有必要了解下MySQL中的latch的概念，在MySQL中，latch是一种轻量级的锁，与lock不同，它锁定的时间特别短，在innodb中，latch又可以分为mutex(互斥量)和rwlock(读写锁)2种，它的目的在于保证并发线程操作临界资源的正确性。
理解了latch的概念，我们看看the fix rule规则：
修改一个数据页，需要获得这个数据页的x-latch；
访问一个页是需要获得s-latch或者x-latch；
持有该页的latch直到修改或者访问该页的操作完成才释放
2、WAL
WAL技术想必大家比较熟悉，它是Innodb存储引擎之所以支持崩溃恢复的根本，也就是持久化一个数据页之前，需要将内存中响应的日志页先持久化
3、force-log-at-commit
这条原则比较重要，它是指在事务提交的时候，其产生的所有MTR日志都要刷到持久化设备中，从而保证崩溃恢复的逻辑。
之所以介绍MTR，是为了后续介绍MySQL8.0的redo log 优化做准备，在MySQL5.7中，mtr保证了事务内部操作的原子性。当用户进行操作的时候，会更新数据页，同时写redo log，mtr是redo log的载体，存在每个连接会话的私有变量中。当mtr提交时，会将本地redo log拷贝到全局的log_buffer中，为了保证redo log的有序性，需要加锁来访问log_buffer，这把锁就是上面提到的mutex，在这个锁保护下，除了要将本地日志拷贝到全局buffer，还需要将数据页加入了flush_list，供后台线程刷脏，辅助数据库检查点持续往前推进，所以这个锁在旧版本的MySQL中竞争非常激烈。MySQL8.0将这个问题进行了优化，后面的文章中将着重分析。
时间原因，先到这里吧。
