1. 事务隔离级别是怎么实现的？

数据库中的**事务（Transaction）**先开启，然后等所有数据库操作执行完成后，才提交事务，对于已经提交的事务来说，该事务对数据库所做的修改将永久生效，如果中途发生中断或错误，那么该事务期间对数据库所做的修改将会被回滚到没执行该事务之前的状态。

2. 事务有哪些特性？

事务是由 MySQL 的引擎来实现的，实现事务必须遵守 4 个特性：

• 原子性（Atomicity）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节，而且事务再执行过程中发生错误，会被回滚到事务开始前的状态。
• 一致性（Consistency）：事务操作前和操作后，数据满足完整性约束，数据库保持一致性状态。
• 隔离性（Isolation）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行导致的数据不一致。
• 持久性（Durability）：事务处理结束后，对数据的修改就是永久的。

InnoDB 引擎通过 redo log（重做日志）保证持久性；通过 undo log（回滚日志）保证原子性；通过 MVCC（多版本并发控制）或锁机制来保证隔离性；一致性是通过持久性+原子性+隔离性来保证。

3. 并行事务会引发什么问题？

MySQL 服务端允许多个客户端连接，这意味着 MySQL 会出现同时处理多个事务的情况。

那么在同时处理多个事务的时候，就可能出现脏读（dirty read）、不可重复读（non-repeatable read）、幻读（phantom read）的问题。

脏读

如果一个事务【读到】了另一个【未提交事务修改过的数据】，就意味着发生了【脏读】现象
比如 A，B 两个事务同时处理，A 事务中间对数据进行了更新，此时 B 正好要读取这个数据，读到了 A 更新后的数据，即使 A 并没有提交。如果 A 发生了回滚，那么 B 读到的就是过期的数据。

不可重复读

在一个事务内多次读取同一个数据，如果出现前后两次读到的数据不一样的情况，就意味着发生了【不可重复读】。
比如 A，B 事务，A 事务先读取了某数据，然后 B 更新了这条数据并提交了事务，那么 A 再次读取此数据的时候，数据不一致。

幻读

在一个事务内多次查询某个符合查询条件的【记录数量】，如果出现前后两次查询到的记录数量不一样的情况，就意味着发生了【幻读】。
比如 A，B 事务，A 事务查询了一个记录范围，B 也查询了相同的范围，但 A 接着插入了一个范围内的记录并提交了事务，B 再次查询时记录和前一次不一样。

4. 事务的隔离级别有哪些？

为了解决【脏读、不可重复读、幻读】的现象，严重性排序为 脏读 > 不可重复读 > 幻读。

SQL 标准提出了四种隔离级别来规避这些现象，隔离级别越高，性能效率就越低：

• 读未提交（read uncommitted），指一个事务还没提交时，它做的变更就能被其他事务看到；可能发生【脏读，不可重复读，幻读】
• 读提交（read committed），指一个事务提交之后，它做的变更才能被其他事务看到；可能发生【不可重复读，幻读】
• 可重复读（repeatable read），指一个事务执行过程中看到的数据，一直跟这个事务启动时看到的数据是一致的，MySQL InnoDB 引擎的默认隔离级别；可能发生【幻读】
• 串行化（serializable）；会对记录加上读写锁，在多个事务对这条记录进行读写操作时，如果发生了读写冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行；

MySQL InnoDB 引擎的默认隔离级别是可重复读，但也能很大程度上避免幻读现象：针对快照读（普通 select 语句），是通过 MVCC 方式解决了幻读，因为即使中途有其他事务插入了一条数据，这个隔离级别下事务执行看到的数据一直跟事务启动时看到的数据一致，所以查询不到新增的数据；针对当前读（select…for update 等语句），是通过 next-key lock（记录锁+间隙锁）方式解决了幻读，因为当执行语句时，加上锁，如果在锁范围内插入了记录，那么插入语句会阻塞。当前读的语句会锁定查询结果中的行，防止其他事务的修改，MVCC+next-key lock能很大程度上保证了不会幻读，但仍可能有特殊情况。

5. Read View 在 MVCC 里是如何工作的？

【读提交】和【可重复读】隔离级别的事务是通过 Read View 来实现的，它们的区别在于创建 Read View 的时机不同，Read View 可以看成一个数据快照，定格某一时刻的数据。【读提交】是在【每个语句执行前】都会重新生成一个 Read View，而【可重复读】是【启动事务时】生成一个 Read View，然后整个事务期间都在用这个 Read View。

Read View 有四个重要的字段：

• m_ids：指的是在创建 Read View 时，当前数据库中【活跃事务】的事务 id 列表，活跃事务是指启动了但还没提交的事务
• min_trx_id：指的是在创建 Read View 时，当前数据库中【活跃事务】中事务 id 最小的事务，也就是 m_ids 的最小值。
• max_trx_id：这个不是 m_ids 的最大值，而是创建 Read View 时当前数据库应该给下一个事务的 id 值，也就是最大的 m_ids + 1。
• creator_trx_id：指的是创建该 Read View 的事务的事务 id。
  
  聚簇索引记录有两个隐藏列：
• trx_id，当一个事务对某条聚簇索引记录进行改动时，就会把该事务的事务 id 记录在 trx_id 隐藏列里；
• roll_pointer，每次对某条聚簇索引记录进行改动时，都会把旧版本的记录写入到 undo 日志中，然后这个隐藏列是个指针，指向每一个旧版本记录，于是就可以通过它找到修改前的记录。
  
  那么创建 Read View 后，记录中的 trx_id 可以划分为以下情况：
  
  一个事务去访问记录的时候，除了自己的更新记录总是可见，还有：
• 如果记录的 trx_id 值小于 Read View 中的 min_trx_id，表示这个版本的记录在创建 Read View 之前提交的事务生成的，所以对当前事务可见
• 如果 trx_id 大于等于 Read View 的 max_trx_id，说明版本记录在 Read View 之后启动的事务生成的，所以不可见
• 如果在之间，则需要判断 trx_id 是否在 m_ids 列表中，如果在，代表依然活跃，所以不可见，如果不在，所以可见

这种通过【版本链】来控制并发事务访问同一个记录时的行为就叫 MVCC（多版本并发控制）。

6. 可重复读是如何工作的？

事务 B 的 id 为 52，此时它的活跃事务 id 列表是 51，52，然后第一次读的时候发现 trx_id 为 50，所以可见，在事务 A 更改后，事务 B 再次读，发现 trx_id 为 51，在活跃 id 列表的最大最小值（min_trx_id，max_trx_id）之间，所以查看事务 A id 51 是否在 m_ids 范围内，发现在，说明还未提交，所以 B 沿着 undo log 的链条找到第一条 trx_id 小于 B 的 min_trx_id 的旧版本的记录。这样就实现了【可重复读】

7. 读提交是如何工作的？

读提交隔离级别每次读取数据时，都会生成一个新的 Read View，所以如果事务 A id 是 51，B 是 52，B 在 第一次读的时候 min_trx_id 是 51，而第二次读的时候因为 A 已经提交了，所以 min_trx_id 是 52，这个时候 51 小于 52，所以 A 修改过的数据版本对 B 是可见的。