提到MySQL，相信大家一定都会想存储引擎，想到存储引擎，就一定会想到InnoDB，而提到InnoDB，就会想到事务，而提到事务，肯定会想到ACID（Atomicity、Consistency、Isolation、Durability，即原子性、一致性、隔离性、持久性），这里就来总结下我所认识的I，即事务隔离。
事务隔离的概念和事务同时执行的问题
首先，我们要知道事务隔离是为什么出现的，一个技术的出现就是为了要解决问题，而事务隔离的出现就是为了解决多个事务同时执行时会出现的三个问题：脏读，不可重复读，幻读。这里先解释下这三个问题的概念。
1.脏读：事务A读取了事务B更新的数据，然后B回滚事务，A读取到的就是脏数据。
2.不可重复读：事务A多次读取同一数据，事务B在事务A多次读取的过程中，对数据做了更新并提交，导致事务A多次读取同一数据时，结果不一致。
3.幻读：事务A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是事务B就在这个时候插入了一条具体分数的记录，当A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样。
事务的隔离级别为：读未提交（read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（serializable ）
读未提交是指，一个事务还没提交时，它做的变更就能被别的事务看到。
读提交是指，一个事务提交之后，它做的变更才会被其他事务看到。
可重复读是指，一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的。
串行化，顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。
这里概念不理解没关系，下面我会用一个例子来说明事务隔离和这几个概念。
隔离级别对应解决的问题
| 事务隔离级别 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|
| 读未提交（read-uncommitten） | 是 | 是 | 是 |
| 读提交（read-committen） | 否 | 是 | 是 |
| 可重复读（repeatable-read） | 否 | 否 | 是 |
| 串行化（serilaizable） | 否 | 否 | 否 |
MySQL的默认隔离级别是RR。
举个栗子🌰
使用如下语句建表
mysql> create table T(c int) engine=InnoDB;
insert into T(c) values(1);
在不同的隔离级别中我们来看看v1，v2，v3的值分别是什么？
若隔离级别是读未提交（RU），v1的值是2，因为在RU中，B未提交的值也被A所看到了，所以：v2的值是2，v3的值是2
若隔离级别是读提交（RC），v1的值是1，事务B在提交后的更新能被A看到，所以v2的值是2，v3的值是2
若隔离级别是可重复读（RR），v1的值是1，v2的值是1，这里之所以是1，是应为在RR中需要遵循：事务在执行期间看到的数据前后必须是一致的，v3的值是2。这里插上一句，如果将查询得到值v2改成：将该数据的值+1，查询得到值v2，那么v2的值是多少呢？v2的值是3，这里为什么没有变成2而变成了3呢？是应为计算v2的时候用的是2来加一的，所以是3。数据的一致性倒是没有被破坏。RR的隔离级别下使用了MVCC（多版本并发控制）机制，select操作不会更新版本号，是快照读（历史版本）；insert、update和delete会更新版本号，是当前读（当前版本）。这里不展开了，以后有时间可以专门针对RR来展开写一篇总结博客。
若隔离级别是串行化，在B更新值的时候，会被锁住，直到事务A提交，B事务才能继续执行，所以v1的值是1，v2的值是1，v3的值是2
总结
从这里我们可以看出每个隔离级别都有自己的使用场景，但是隔离级别越高，执行的效率就越低，所以要根据自己的业务场景来选择合适的隔离级别。
