InnoDB事务篇
1、解决数据更新丢失的问题
1)LBCC:基于锁的并发控制。让操作串行化执行。效率低。
2)MVCC:基于版本的并发控制。使用快照形式。效率高。读写不冲突。主流数据库都是使用的MVCC。
2、InnoDB中MVCC的实现
特点:读不加锁,读写不冲突
实现方案:基于undolog+readview实现的。
1)undolog
回滚日志。需要在undolog中记录未提交操作的原始状态。
在undolog中会记录版本信息。在每一行记录上都有2-3个隐藏列。如果表没有主键时就是3个,如果有主键就是两个。
隐藏列:
rowid:如果没有主键,会自动生成一个隐藏列。
回滚指针:指向记录的上一个版本。
事务id:记录了操作这条记录的事务id。
事务id在mysql中每个事务都有一个唯一的id,并且是自增的。
每次更新时,都是生成一个新的版本,并且由回滚指针指向旧版本。就会形成一个版本链。后台有个purge线程执行清理操作。删除记录时,是在记录上打上删除标记,并不直接删除。
2)readview
生成一个readview相当于生成了一个快照。只要是ReadView不发生变化读到的结果就是相同的。
readview是一个数组,生成的时机是执行select操作时生成。数组m_ids,其中记录的当前时刻,数据库中活跃的事务id列表。
例如:
m_ids:[105,110,111,120]
可见性判断条件:
- 如果被访问版本的trx_id
属性值小于m_ids
列表中最小的事务id,表明生成该版本的事务在生成ReadView
前已经提交,所以该版本可以被当前事务访问。
- 如果被访问版本的trx_id
属性值大于m_ids
列表中最大的事务id,表明生成该版本的事务在生成ReadView
后才生成,所以该版本不可以被当前事务访问。
- 如果被访问版本的trx_id
属性值在m_ids
列表中最大的事务id和最小事务id之间,那就需要判断一下trx_id
属性值是不是在m_ids
列表中,如果在,说明创建ReadView
时生成该版本的事务还是活跃的,该版本不可以被访问;如果不在,说明创建ReadView
时生成该版本的事务已经被提交,该版本可以被访问。
支持两种事务隔离级别:RC、RR。
读未提交和串行化和MVCC没有关系。
一个select对应一个ReadView(m_ids),select语句执行完毕后ReadView就失效。
如果当前数据库中没有活跃事务,那么ReadView(m_ids)中就包含将要生成的事务id。
3)RC事务隔离级别的实现
读已提交,当前事务中可以读取到其他事务提交的结果。
实现方案:在当前事务中执行select查询,就会生成一个ReadView。如果同一个select再次执行,会再次生成ReadView。
4)RR事务隔离级别
可重复读,当前事务中select语句多次执行得到的结果是相同的,无论其他事务是否已经提交。
实现方案:在当前事务中执行select查询,就会生成一个ReadView,之后同一个select使用同一个ReadView。
5)小结:RC和RR的区别
READ COMMITTD
、REPEATABLE READ
这两个隔离级别的一个很大不同就是生成ReadView
的时机不同,READ COMMITTD
在每一次进行普通SELECT
操作前都会生成一个ReadView
,而REPEATABLE READ
只在第一次进行普通SELECT
操作前生成一个ReadView
,之后的查询操作都重复这个ReadView
就好了。