一文解决MySQL事务并发问题和事务隔离级别及MVCC原理
事务并发产生的一致性问题
脏写
如果一个事务修改了另一个未提交事务的修改过的数据，则称发生了脏写现象。
举个例子：
假设数据库中有一个数据项为x=2；
事务A修改了x=1；此时事务A并没有提交，事务B此时也来修改数据项x=0；此时事务A,B提交
事务B修改了事务A未提交修改过的数据，所以发生了脏写的现象
脏读
如果一个事务读取了另一个事务未提交的数据，则称发生了脏读现象
不可重复读
如果一个事务A读取了x的值，然后事务B又修改了x的值并且提交，事务A再次读取x的值时，则会与第一次x的值不同，则称发生了不可重复读（也就是两次读的结果不一样）。
注意：如果事务发生了update更新值，delete删除记录，则可以把这种现象叫做不可重复读
幻读
当一个事务A读取符合搜索条件的记录数为x，此时另一个事务B往符合条件里插入了一条行数据并提交，此时事务A再去读符合条件的记录数时，则跟原来的不一样，则称发生了幻读。
注意：如果事务发生了insert插入符合条件的记录，或则是update修改了记录的键值导致插入符合记录数里，则可以把这种现象叫做幻读
SQL标准对这里的不可重复读和幻读有点描述不清，我们一般认为:
幻读强调的是在后读取到了之前没有读取到的数据，这个没有读取到的数据，可能是insert或则update插入的不可重复读的话，则是updata和delete
SQL标准中的四种隔离级别
| 隔离级别 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|
| READ UNCOMMITTED | 可能 | 可能 | 可能 |
| READ COMMITTED | 不可能 | 可能 | 可能 |
| REPETABLE READ | 不可能 | 不可能 | 可能 |
| SERIALIZABLE | 不可能 | 不可能 | 不可能 |
MySQL支持的四种隔离级别
oralce支持两种隔离级别：read committed和serializable
mysql支持虽然支持四种隔离级别，但是mysql的repeatable read隔离级别不允许幻读
MVCC原理
实现MVCC关键：隐藏字段，undo log，ReadView
版本链
对于聚簇索引记录来讲，每个行格式都包含了两个必须的隐藏列
- row_id不是必须的，只有在没有主键或者没有非空的unique字段时，才会有row_id；
- trx_id事务id是必须有的；一个事务在对记录进行修改后，都会将该事务的id写入记录的trx_id中
- roll_point回滚指针，指向上一个版本的记录，相当于一个指针
这里insert log日志在只在事务回滚时起作用，事务提交后该日志文件就被系统回收了(可能是被重用或则释放了)。
虽然insert undo日志被真正回收了，但是回滚指针的值并没有清除，如果roll_point第一个字节是1的话，表示它是一个insert undo日志
现在假设我们的数据库中发生了如下事务：
那么对应的版本链则如下图：
每次事务更新该行时，都会将事务id写入trx_id中。将旧记录写入undo 日志中，每条undo日志中也会有roll_point属性，其他字段只包含索引列和更新的列(insert的undo日志中没有该属性，因为insert没有旧版本)。这些undo日志通过roll_point形成一个版本链。
我们后面会通过该记录的版本链来控制并发事务可以访问到的记录，我们把这种机制叫做MVCC多版本并发控制
注意：这里undo日志并不是全部字段都有，只会包含一些索引列和被更新的字段
比如我们上面的class字段，undo日志里是没有记录这个字段的，因为它并没有被更新，如果该版本没有这个字段，说明它是和上一个版本字段值相同
ReadView
使用uncommitted read隔离级别时，由于可以读到未提交的值，所以直接读取最新版本的值即可。使用可串行化隔离级别时，使用加锁来访问记录。
对于读已提交和不可重复读这两个隔离级别时，由于不能读取未提交事务的值，所以我们必须控制它可以读取的记录，故而提出了ReadView的概念
ReadView主要包含以下四个重要的内容：
m_ids：在生成readview时，当前活跃的事务id
min_trx_id：当前活跃事务中，id最小的值
max_trx_id：表示生成该readview时，分配给下一个事务的事务id
注意：max_trx_id并不是m_ids中的最大值，事务id是递增分配的。
- 比如，现在有id为1， 2，3这三个事务，之后id为3的事务提交了。
那么一个新的读事务在生成ReadView时，m_ids就包括1和2，min_trx_id的值就是1，max_trx_id的值就是4
creat_trx_id：创建该readview的事务id
只有执行insert，update，delete操作时，才会给它分配事务唯一id，执行select操作不会给它分配事务id，默认都为0
有了这个readview和版本链后，我们就可以根据这些判断该记录是否可见了：
- 如果记录中的trx_id和readview中的create_trx_id值相同时，则说明这个记录是该事务修改的，则表示可以读取
- 如果记录中的trx_id小于readview中的min_trx_id值，则说明生成该readview时，修改该记录的事务已经提交，可以被读取
- 如果记录中的trx_id大于readview中max_trx_id值，则说明生成该readview时，修改该记录的事务还没有创建出来，说明它是不可被读取的
- 如果记录汇总的trx_id小于readview的最大值事务id，大于readview的最小值事务id。则查看它是否则活跃事务列表里，如果在的话，说明生成该readview时，该事务还没有被提交，则不可读取该记录。否则说明已提交，可以读取
如果该版本对该事务不可见，则顺着版本链往下找，直到记录可见。如果到最后都没有可见的记录，则说明该记录不可见，不能包含到结果集中
读已提交和可重复读：最大的区别在于生成readview的时机不一样
因为读已提交是不能解决不可重复读的，所以一个事务中两次读取的记录会不一样，所以每执行一个select操作都会生成一个readview。
而可重复读在一个事务中两次读取的记录必须是一样的，所以在该隔离级别下只有第一次select操作会生成一个readview，后续的select操作会复用这个readview
二级索引与MVCC
前面我们讲的行记录中都是包含trx_id和roll_point隐藏列的，那么二级索引是没有隐藏列的，那么我们通过二级索引查找记录时，如何判断它的可见性呢？？？
比如下面这个事务
begin；
select name from user where name=‘刘备’；
此时我们的查询优化器决定了要到二级索引中查找name为‘刘备’的记录，那么该如何判断该记录可见呢？？可分为以下两步：
- 二级索引页面的Page Header部分有一个名为PAGE_MAX_TRX_ID的属性，每次对该页面做增删改操作时，判断该事务的id是否大于PAGE_MAX_TRX_ID的值，如果大于，则把PAGE_MAX_TRX_ID的值更新为事务id值。那么我们的事务在select查询时，如果readview中的最小事务id大于PAGE_MAX_TRX_ID的值，则说明最后修改该页面的事务早就提交了，此页面全部可以访问。否则的话，就需要进行第二部操作，回表
- 通过name找到聚簇索引的记录，然后通过前面的方式找到可见的第一个版本，如果该版本的name符合‘刘备’，则把该记录返回。否则查找下一个记录(不是查找下一个版本哦)
补充：关于purge
我们知道在insert操作时，事务提交后就可以释放掉了，而进行delete操作和更新键值的updata操作时，并不会立即删除记录，而是给该记录打一个删除标记，其主要就是为了给MVCC服务。那么总不可能一直不删除记录吧！！那存储空间不得爆了！！
处理这些记录的操作我们叫做purge操作，主要的问题就是什么时候处理？？？
简单一句话：当系统中最早产生的readview不再访问他们了，那么就可以清理了。那么什么时候才表示肯定不再访问它们了呢？只要在生成readview时，保证某个事务已经提交，就说明该readview不会访问该事务的updata undo日志了
详见《MySQL是怎样运行的》P398