1.四个问题
问题 | 英文 | 解释 |
---|---|---|
脏写 | Dirty Write | 一个事务修改了另一个未提交事务修改的数据 |
脏读 | Driry Read | 一个事务读取到了另一个未提交事务修改的数据 |
不可重复度 | Non-Repeatable Write | 一个事务中多次读取其他事务已提交的数据 |
幻读 | Phantom | 如果一个事务先根据某些条件查询出一些记录,之后另一个事务又向表中插入了符合这些条件的记录,原先的事务再次按照该条件查询时,能把另一个事务插入的记录也读出来,那就意味着发生了幻读 |
上述四个问题严重性:脏写>脏读>不可重复读>幻读
2.四个隔离级别
隔离级别 | 英文 | 解释 |
---|---|---|
读未提交 | Read Uncommited | 可以读取到为提交事务修改的数据 |
读已提交 | Read Commited | 只能读取到已经提交事务修改的数据 |
可重复读 | Read Repeatable | 可以重复读 |
可序列化 | Serializable | 并发的事务可转换成串行执行 |
脏写问题最严重,在事务并发的任何阶段都不可以发生,四个事务隔离等级也都不会发生脏写。下面来讨论一下四个隔离级别在其他三个问题上的情况:
隔离级别 | 脏读 | 不可重复度 | 幻读 |
---|---|---|---|
读未提交 | √ | √ | √ |
读已提交 | × | √ | √ |
可重复读 | × | × | √ |
可串行化 | × | × | × |
mysql默认的事务隔离级别是可重复读
3.MVCC
mysql事务在并发执行的时候,如何做到读已提交或可重复读的事务隔离级别呢?它是通过MVCC实现的。
MVCC(Multi-Version Concurrency Control 多版本并发控制):在使用READ COMMITTD
、REPEATABLE READ
这两种隔离级别的事务在执行普通的SELECT
操作时访问记录的版本链的过程,这样子可以使不同事务的读-写
、写-读
操作并发执行,从而提升系统性能。
READ COMMITTD
、REPEATABLE READ
这两个隔离级别的一个很大不同就是:生成ReadView的时机不同,READ COMMITTD在每一次进行普通SELECT操作前都会生成一个ReadView,而REPEATABLE READ只在第一次进行普通SELECT操作前生成一个ReadView,之后的查询操作都重复使用这个ReadView就好了
3.1 版本链
对于使用InnoDB
存储引擎的表来说,它的聚簇索引记录中都包含两个必要的隐藏列(row_id
并不是必要的,我们创建的表中有主键或者非NULL的UNIQUE键时都不会包含row_id
列)
- trx_id:每次一个事务对某条聚簇索引记录进行改动时,都会把该事务的
事务id
赋值给trx_id
隐藏列。 - roll_pointer:每次对某条聚簇索引记录进行改动时,都会把旧的版本写入到
undo日志
中,然后这个隐藏列就相当于一个指针,可以通过它来找到该记录修改前的信息。
每次对某条聚簇索引记录进行改动时,都会把旧的版本写入到undo日志
中,然后这个隐藏列就相当于一个指针,可以通过它来找到该记录修改前的信息
对该记录每次更新后,都会将旧值放到一条undo日志
中,就算是该记录的一个旧版本,随着更新次数的增多,所有的版本都会被roll_pointer
属性连接成一个链表,我们把这个链表称之为版本链
,版本链的头节点就是当前记录最新的值。另外,每个版本中还包含生成该版本时对应的事务id
,这个信息很重要,我们稍后就会用到。
3.2 Read View
对于使用READ UNCOMMITTED
隔离级别的事务来说,由于可以读到未提交事务修改过的记录,所以直接读取记录的最新版本就好了;对于使用SERIALIZABLE
隔离级别的事务来说,设计InnoDB
的大叔规定使用加锁的方式来访问记录(加锁是啥我们后续文章中说哈);对于使用READ COMMITTED
和REPEATABLE READ
隔离级别的事务来说,都必须保证读到已经提交了的事务修改过的记录,也就是说假如另一个事务已经修改了记录但是尚未提交,是不能直接读取最新版本的记录的,核心问题就是:需要判断一下版本链中的哪个版本是当前事务可见的。为此,设计InnoDB
的大叔提出了一个ReadView
的概念,这个ReadView
中主要包含4个比较重要的内容:
- min_ids:表示在生成
ReadView
时当前系统中活跃的读写事务的事务id
列表。 - min_trx_id:表示在生成
ReadView
时当前系统中活跃的读写事务中最小的事务id
,也就是m_ids
中的最小值。 - 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。 - creator_trx_id:表示生成该
ReadView
的事务的事务id
。只有在对表中的记录做改动时(执行INSERT、DELETE、UPDATE这些语句时)才会为事务分配事务id,否则在一个只读事务中的事务id值都默认为0。
有了这个ReadView
,这样在访问某条记录时,只需要按照下边的步骤判断记录的某个版本是否可见:
- 如果被访问版本的
trx_id
属性值与ReadView
中的creator_trx_id
值相同,意味着当前事务在访问它自己修改过的记录,所以该版本可以被当前事务访问。 - 果被访问版本的
trx_id
属性值小于ReadView
中的min_trx_id
值,表明生成该版本的事务在当前事务生成ReadView
前已经提交,所以该版本可以被当前事务访问。 - 如果被访问版本的
trx_id
属性值大于或等于ReadView
中的max_trx_id
值,表明生成该版本的事务在当前事务生成ReadView
后才开启,所以该版本不可以被当前事务访问。 - 如果被访问版本的
trx_id
属性值在ReadView
的min_trx_id
和max_trx_id
之间,那就需要判断一下trx_id
属性值是不是在m_ids
列表中,如果在,说明创建ReadView
时生成该版本的事务还是活跃的,该版本不可以被访问;如果不在,说明创建ReadView
时生成该版本的事务已经被提交,该版本可以被访问。
如果某个版本的数据对当前事务不可见的话,那就顺着版本链找到下一个版本的数据,继续按照上边的步骤判断可见性,依此类推,直到版本链中可见的那个版本为止。如果最后一个版本也不可见的话,那么就意味着该条记录对该事务完全不可见,查询结果就不包含该记录。
在MySQL
中,READ COMMITTED
和REPEATABLE READ
隔离级别的的一个非常大的区别就是它们生成ReadView的时机不同:
- Read Commited:每次读取数据前都生成一个ReadView
- Read Repeatable:在第一次读取数据时生成一个ReadView