事务的ACID特性
原子性: 一个事务中的操作要么全部都执行,要么都不执行。
一致性: 指在事务开始之前和事务结束以后,数据不会被破坏,假如A账户给B账户转10块钱,不管成功与否,A和B的总金额是不变的。
隔离性: 多个事务并发访问时,事务之间是相互隔离的,一个事务不应该被其他事务干扰,多个并发事务之间要相互隔离。。
持久性: 表示事务完成提交后,该事务对数据库所作的操作更改,将持久地保存在数据库之中。
事务并发存在的问题
事务并发会引起脏读、不可重复读、幻读问题。
脏读:如果一个事务读取到了另一个未提交事务修改过的数据,我们就称发生了脏读现象。
不可重复读:同一个事务内,多次读取某一数据结果不一样(两次读取之间其他事务修改了数据并提交了事务)。
幻读:如果一个事务先根据某些搜索条件查询出一些记录,在该事务未提交时,另一个事务写入了一些符合那些搜索条件的记录(如insert、delete、update),就意味着发生了幻读。(两个查询条件为where id > 2的查询之间另一个事务插入了一条id > 2的数据导致结果不同)
四大隔离级别
为了解决并发事务存在的脏读、不可重复读、幻读等问题,数据库大叔设计了四种隔离级别。分别是读未提交,读已提交,可重复读,串行化(Serializable)。
读未提交:即使事务未提交也能被其他事务读取到它修改的数据。
读已提交:当前事务只能读取到其他事务已经提交的数据。
可重复读:读取数据的时候不能修改,解决了可重复读的问题。
串行化:所有事务进行串行化顺序执行,性能低。
隔离级别 | 脏读 | 不可重复读 | 幻读 |
读未提交 | √ | √ | √ |
读已提交 | × | √ | √ |
可重复读 | × | × | √ |
串行化 | × | × | × |
MVCC
MVCC,即Multi-Version Concurrency Control (多版本并发控制)。它在数据库中存有每一行数据的多个版本,并根据隔离级别和事务id判断当前事务能读取到哪些历史版本。数据库隔离级别读已提交、可重复读 都是基于MVCC实现的,它比串行化加锁快多了。
如何实现的
事务ID
根据事务开启的先后获取一个自增的事务ID。
隐式字段
InnoDB中含有隐式字段trx_id、roll_pointer分别用于记录操作该数据的事务ID和一个指向回滚undo日志的指针。
undo log:
回滚日志,用于记录数据被修改前的信息。在表记录修改之前,会先把数据拷贝到undo log里,如果事务回滚,即可以通过undo log来还原数据。
Read View
它就是事务执行SQL语句时,产生的读视图,一个事务内肯能会生成多个版本的Read View。它是用来做可见性判断的,判断当前事务可以读取到undo log上的哪些版本。
Read View中的几个重要属性
m_ids: begin了但未submit的事务id,它数据结构为一个List。
min_limit_id:即m_ids中的最小值。
max_limit_id:表示生成ReadView时,系统中应该分配给下一个事务的id值。
creator_trx_id: 创建当前read view的事务ID
Read view 匹配条件规则
如果undo log数据事务ID trx_id < min_limit_id,表明生成该版本的事务在生成Read View前就已经提交了,所以该版本可以被当前事务访问。
如果trx_id>= max_limit_id,表明生成该版本的事务在生成ReadView后才生成,所以该版本不可以被当前事务访问。
如果 min_limit_id =<trx_id< max_limit_id,需要分3种情况讨论
这个事务还未提交,但是如果数据的trx_id等于creator_trx_id的话,表明数据是自己生成的,因此是可见的。
trx_id不等于creator_trx_id,则Read View生成时,事务未提交,并且不是自己生产的,所以当前事务也是看不见的;
如果m_ids不包含trx_id,则说明你这个事务在Read View生成之前就已经提交了,修改的结果,当前事务是能看见的。
不同隔离模式下Read View的工作模式不同
在读已提交模式下,每一次查询都会产生一个新的Read View副本。
在可重复读模式下,一个事务里只会获取一次read view,都是副本共用的,从而保证每次查询的数据都是一样的。
参考
https://juejin.cn/post/7016165148020703246?utm_source=gold_browser_extension