事务并发可能出现的问题
事务的4个隔离级别,以及解决的问题
四个隔离级别和可以解决的问题是SQL专门规定的,但是在Innodb引擎下,在可重复读的隔离级别的下就可以直接解决幻读的问题。
我们可以在启动时指定系统参数修改系统默认的隔离级别,默认为可重复读。
mysql> show variables like 'transaction_isolation';+-----------------------+-----------------+| Variable_name | Value |+-----------------------+-----------------+| transaction_isolation | REPEATABLE-READ |+-----------------------+-----------------+1 row in set, 1 warning (0.00 sec)我们在前面就讲过了undo日志,对于每次进行增删改就会产生undo日志,这时每个数据行的roll_pointer就会指向一个undo链表,我们就称其为版本链。我们在提一嘴,因为insert的undo日志在提交后是没有用的,所以在事务提交后insert的undo就会被释放。
可以到前面的文章了解一下undo日志。大概知道undo日志的类型和产生的过程就OK了感觉怎么存储undo日志的那一部分讲得云里雾里https://www.cnblogs.com/duizhangz/p/16333565.html
为什么没用?因为插入并不维护旧值,只是表明一个插入,并不需要存储什么信息。所以在事务提交时直接释放掉。因为事务在回滚时需要由一条insert语句类型的undo进行回滚。

这就是上面俩事务生成的版本链。

undo链表头存储的就是最新事务更新的记录信息。
对于不同的事务隔离级别,我们可以读取的记录数据是不一样的。
对于未提交读的隔离级别来说,我们可以直接读到数据的最新版本。
对于提交读的隔离级别来说,我们需要可以读到的就是已经提交的事务的修改数据。
对于可重复读的隔离级别来说,我们需要可以读到在事务开启前已经提交的事务的数据。
对于串行读的隔离节别来说,Innodb采用加锁的方式来保证串行读。
对于中间两个隔离级别,就需要ReadView这个结构来实现MVCC。以下是ReadView的结构
有了ReadView这个结构,我们在就可以对事务进行控制。
当前情况在版本链中从头到尾遍历,直到获得到数据。
上面提到的提交读和可重复读,因为是两个隔离级别有区别的,两个隔离级别的实现只要在ReadView的时机上进行把控,就可以实现。
仔细品一品,一下就可以恍然大悟。
这个MVCC只会在我们使用普通select查询才会生效。