问题：请讲下mysql的事务是如何实现的
分析：该问题主要考察对事务的理解及实现方式；
回答要点：
主要从以下几点去考虑，
1、对事务的概念的理解？
2、事务的实现方式？
讲到mysql的事务，很快可以想到事务的4大特性，那就是ACID，具体说来就是原子性、一致性、隔离性、持久性。也就是说事务就是围绕这4个特性来展开的。其中隔离性中又定义了隔离级别，有读未提交、读已提交、可重复度、可串行化这样4个级别。
对于事务的4个特性，原子性、一致性、持久性说的都是mysql的可靠性方面的考量，对应隔离性说的则是在并发场景下，同时有读和写的情况如何做到数据隔离，到底数据要隔离到什么程度，则就有了隔离级别的概念。
mysql要保证事务的4大特性，主要使用了日志（redo log、undo log）、锁技术、MVCC技术
日志
说到日志，平时接触最多的是mysql的binlog日志，主要用来记录mysql执行的更新语句，用在主从复制的场景比较多。今天来说的日志却不包含binlog，今天来说redo log和undo log
redo log
又叫重做日志，用来实现事务的持久性，包含重做缓冲区和重做日志文件两部分，前者在内存中，后者在磁盘。mysql在事务提交前会把所有的修改信息都记录在redo log中。
为什么要引入redo log那，原来mysql为了提高性能不会把每次的修改都实时同步到磁盘中，而是先存到buffer pool中，然后后台有一个线程来进行buffer pool和磁盘之间的同步。这样就存在一个问题，如果还没来得及进行buffer pool和磁盘的同步，机器宕机了怎么办，那么数据岂不是要丢失，为了解决这个问题，引入了redo log，在事务开始时把修改记录到重做缓冲区，在事务提交前将重做缓冲区的内容刷到磁盘上，不禁要问这不是多此一举吗，我实时把buffer pool中的内容写入磁盘不也可以达到这样的目的，哈哈，肯定不是这样的，因为redo log的文件是顺序写，而buffer pool和磁盘的写是随机写，顺序写的速度要比随机写快很多，所以这就是引入redo log的目的。
undo log
又叫回滚日志，用来保证事务的原子性。用来记录数据被修改前的信息，和redo log正好相反，redo log是记录修改以后的记录。undo log记录的是数据的逻辑变化，为了在发生错误时进行数据的回滚操作。
锁技术
当多个请求同时到达mysql服务器，如果都是读请求，那么可以不采取任何的措施，如果既有读请求又有写请求的前提下，必须要有一种机制来规范读写请求，不然很容易造成数据的不一致，这时就有了锁机制，使用读锁和写锁进行控制即可，读锁对所有的读操作都是共享的，不会造成阻塞；写锁则是排他锁，不能做到写读、写写并行。
MVCC
MVCC叫做多版本并发控制，通过在每条记录的后边保存两个隐藏的列来实现，一个保存行创建的时间，一个保存行的过期时间，保存的不是时间而是系统版本号，通过MVCC来做到读写分离。
在事务的4大特性中隔离性是最复杂的，4种隔离级别分别定义了一个事务种的修改哪些是事务之间可见的，哪些是事务之间不可见的。
读未提交
读未提交是读的情况下不加任何的锁，所以会读到其他事务未提交的数据，造成脏读数据
读已提交
在该隔离级别下，读操作是不加锁的，采用MVCC的方式进行读取；写操作加排他锁，也就是写锁。该级别会产生不可重复读和幻读的情况。
不可重复读指的是两次的读数据内容发生了变化，行数未变，针对update操作；幻读是两次的读数据内容未变，行数发生了变化，针对insert、delete操作；
在读已提交隔离级别下实现的MVCC机制是这样的，每次的select操作都会生成一个新的版本号，所以每次的读取都是不同的副本，那么就存在不可重复读和幻读
可重复读（mysql默认隔离级别）
在一个事务中多次的读取结果是一样的。有两种机制可以实现这种效果，分别是读写锁和MVCC。
使用读写锁实现的话，优点是实现简单，但是读写无法并行。
使用MVCC机制实现优点是实现复杂，但读写可并行。在这种情况下实现的MVCC，每次的select操作都是使用最开始的版本号，所以每次的读取都是相同的数据，不会产生不可重复读，但是会产生幻读的情况，mysql通过next-key锁（行锁+间隙锁）的方式解决了幻读。
参考：https://www.sohu.com/a/316482862_663371
https://www.cnblogs.com/zhiqian-ali/p/5668199.html