MySQL事务

开启事务

执行「开始事务」命令，并不意味着启动了事务。在 MySQL 有两种开启事务的命令，分别是：

• begin/start transaction 命令：并不代表事务启动了，只有在执行这个命令后，执行了第一条 select 语句，才是事务真正启动的时机；
• start transaction with consistent snapshot 命令：马上启动事务。

事务的特性

        事务是由 MySQL 的引擎来实现的，我们常见的 InnoDB 引擎它是支持事务的，MyISAM不支持事务。要实现事务必须要遵守 4 个特性，分别如下：

• 原子性（Atomicity）：一个事务要么全部失败，要么全部成功，不会出现中间状态。
• 一致性（Consistency）：事务操作前后，数据满足完整性约束，数据库保持一致性状态。
• 隔离性（Isolation）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。
• 持久性（Durability）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

Innodb实现上面这四个特性的技术：

• 原子性：通过undo log来保证
• 一致性：通过持久性+原子性+隔离性来保证；
• 隔离性：通过MVCC机制或锁机制来保证
• 持久性：通过redo log来保证

并行事务引发的问题

脏读

        一个事务读取到一个未提交事务修改的数据就是脏读。

因为事务没有提交，事务A随时可能发生回滚，这样事务B读到的数据就会是过期数据。

不可重复读

        在一个事务中多次读取同一个数据，读取的结果不相同，这就是不可重复读问题。

幻读

        在某个事务中多次查询符合条件的记录数量，如果出现前后两次查询到的记录数量不一样的情况，就意味着发生了幻读现象。

事务的隔离级别

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

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

针对不同的隔离级别，并发事务时可能发生的现象也会不同。

MySQL InnoDB 引擎的默认隔离级别虽然是「可重复读」，但是它很大程度上避免幻读现象（并不是完全解决了），解决的方案有两种：

• 针对快照读（普通 select 语句），是通过 MVCC 方式解决了幻读，因为可重复读隔离级别下，事务执行过程中看到的数据，一直跟这个事务启动时看到的数据是一致的，即使中途有其他事务插入了一条数据，是查询不出来这条数据的，所以就很好了避免幻读问题。
• 针对当前读（select ... for update 等语句），是通过 next-key lock（记录锁+间隙锁）方式解决了幻读，因为当执行 select ... for update 语句的时候，会加上 next-key lock，如果有其他事务在 next-key lock 锁范围内插入了一条记录，那么这个插入语句就会被阻塞，无法成功插入，所以就很好了避免幻读问题。

读已提交

        读已提交每次查询都会生成ReadView。

可重复读

        可重复读隔离级别是启动事务时生成一个 Read View，然后整个事务期间都在用这个 Read View。

        在可重复读隔离级别中，普通的 select 语句就是基于 MVCC 实现的快照读，也就是不会加锁的。而 select .. for update 语句就不是快照读了，而是当前读了，也就是每次读都是拿到最新版本的数据，但是它会对读到的记录加上 next-key lock 锁。

可重复读幻读问题

上面介绍了可重复读解决幻读问题的办法，但是并不是完全避免了幻读问题。

快照读

        快照读解决幻读问题在MVCC的介绍说过了，就是通过记录的trx_id在ReadView中进行比对，不可见就顺着undo log的版本链找到可见的版本。

当前读

        MySQL 里除了普通查询是快照读，其他都是当前读，比如 update、insert、delete，这些语句执行前都会查询最新版本的数据，然后再做进一步的操作。另外，select ... for update 这种查询语句是当前读，每次执行的时候都是读取最新的数据。

        Innodb 引擎为了解决「可重复读」隔离级别使用「当前读」而造成的幻读问题，就引出了间隙锁。

        假设，表中有一个范围 id 为（3，5）间隙锁，那么其他事务就无法插入 id = 4 这条记录了，这样就有效的防止幻读现象的发生。

        事务 A 执行了这面这条锁定读语句后，就在对表中的记录加上 id 范围为 (2, +∞] 的 next-key lock（next-key lock 是间隙锁+记录锁的组合），后续事务B在操作就被阻塞。

上面已经很大程度解决了幻读问题，但是有些情况还是会发生幻读，比如下面的例子：

开启事务A，查询id=5的数据，这里查询不到

begin;

select * from t_stu where id = 5;

开启事务B，添加一条id=5的数据，并且提交事务

begin;

insert into t_stu values(5, '小美', 18);

commit;

此时，事务 A 更新 id = 5 这条记录，对没错，事务 A 看不到 id = 5 这条记录，但是他去更新了这条记录，这场景确实很违和，然后再次查询 id = 5 的记录，事务 A 就能看到事务 B 插入的纪录了，幻读就是发生在这种违和的场景。

update t_stu set name = 'aaaaa' where id = 5;

select * from t_stu where id = 5;

在可重复读隔离级别下，事务 A 第一次执行普通的 select 语句时生成了一个 ReadView，之后事务 B 向表中新插入了一条 id = 5 的记录并提交。接着，事务 A 对 id = 5 这条记录进行了更新操作，在这个时刻，这条新记录的 trx_id 隐藏列的值就变成了事务 A 的事务 id，之后事务 A 再使用普通 select 语句去查询这条记录时就可以看到这条记录了，于是就发生了幻读。

因为这种特殊现象的存在，所以我们认为 MySQL Innodb 中的 MVCC 并不能完全避免幻读现象。

除了上面这一种场景会发生幻读现象之外，还有下面这个场景也会发生幻读现象：

T1 时刻：事务 A 先执行「快照读语句」：select * from t_test where id > 100 得到了 3 条记录。
T2 时刻：事务 B 往插入一个 id= 200 的记录并提交(锁释放)；
T3 时刻：事务 A 再执行「当前读语句」 select * from t_test where id > 100 for update 就会得到 4 条记录，此时也发生了幻读现象。

要避免这类特殊场景下发生幻读的现象的话，就是尽量在开启事务之后，马上执行 select ... for update 这类当前读的语句，因为它会对记录加 next-key lock，从而避免其他事务插入一条新记录。