大型网站建设历史,网站重构,保定专业做网站的公司,做运营那些无版权图片网站人阅读
一、说到mvcc就少不了事务隔离级别#xff08;大白话解释#xff09; 序列化#xff08;SERIALIZABLE#xff09;#xff1a;事务之间完全隔离#xff0c;当成一个序列#xff0c;一个一个执行。
1
可重复读#xff08;REPEATABLE READ#xff09;#xff…人阅读
一、说到mvcc就少不了事务隔离级别大白话解释 序列化SERIALIZABLE事务之间完全隔离当成一个序列一个一个执行。
1
可重复读REPEATABLE READ不会被看成一个序列但是这个事务里发生的改变另一个事务中是看不到的即同时执行两个select结果是一样的。默认
1
提交读READ COMMITTED这个事务里发生改变并且提交在另一个事务里是可见的两条select中间提交过数据两次结果可能不同。
1
未提交读READ UNCOMMITTED可以读到未提交的数据容易产生幻读脏读。
1
幻读和脏读
幻读是每次查询的数据不一样。
脏读是查询到了错误的数据。查询到结果后有个事务回滚了 二、mvcc
三个隐藏字段
DB_TRX_ID:记录最近更新这条行记录的事务ID大小为6个字节。
DB_ROLL_PTR:表示指向该行回滚段的指针innodb便是通过这个指针找到之前的版本数据。该行记录上所有旧版本在undo中都通过链表的形式组织。
DB_ROW_ID:行标识如果表没有主键就会生成一个隐藏的主键。 三
MyISAM不支持事务所以这里就说InnoDB undo log是为了回滚用的。 虽然mvcc保证了读是一致的能解决幻读但是那是历史数据并不是真的数据涉及到的列我直接锁住别的事务在这里阻塞。 问那提交读就不锁了吗 提交读中没有加间隙锁。但肯定使用了行锁只有提交之后才能修改 事务和锁区别对待
问可提交读为啥不能解决幻读可重复读为啥能解决幻读 后者间隙锁 仅仅行锁无法保证幻读除非表锁。 这里说明可提交读如果表锁就能保证幻读。行锁的时候就无法保证幻读。 未提交读 直接读取最新的数据 已提交读 每次查询的时候生成一个readview快照 可重读读 第一次读的时候生成一个快照以后的就直接取这个快照 串行化因为加锁也不存在这个问题 几个数据
当前活跃的事务id们 活跃最小 活跃最大1就是下次事务的id 当前的事务id 判断版本 1、如果版本和当前的是事务一样就说明是当前的事务做的修改可以直接使用
2、判断是不是小于最小活跃如果小于则说明生成readView的时候已经提交了可以读
3、如果大于等于活跃最大1,就说明是在这个事务之后开启的不可见
4、如果是处于活跃列表中则说明创建readView的时候不在活跃列表中就说明当时未提交继续往前找
