原文来自极客时间, 第八讲:事务隔离[mysql实战45讲]
图1
一:总括:
1. begin / start transaction 并不是事务起点, 而是他们之后的第一个操作innodb表的语句.
2. 马上启动事务 : start transaction with consistent snapshot
3. 事务A看的到k 是1; 因为一致性视图在start transaction whit consistent snapshot时创建;
4. 事务B看到的k 是 2: 因为 事务C是最先提交的, update有排他锁, 所以事务B的update 和事务CD的update冲突了, ==> 有疑问!
二: "快照"在MVCC中是怎么工作的 ?
1.疑问: 什么是MVCC ? ==> Multi-Version Concurrency Control 多版本并发控制
1: MVCC步骤:
1.事务启动时, 创建快照; 基于整个库
唯一的事务id ==> transaction id
数据版本的事务ID ==> row trx_id
2.行状态变更图
名词解释:
1.事务ID : 唯一的, 递增的
2.一致性视图数组 read - view : 保存事务启动瞬间"活跃"的事务ID, 由高水位, 低水位组成.
3.活跃: 启动但未提交
4: 低水位: 数组中事务ID最小值
5: 高水位: 当前系统创建过的事务ID最大值
注意: 获取视图数组高低水位, 是原子操作,期间不能创建新事务.
3.数据版本可见性规则
6:row trx_id: 行数据版本, 哪个事务更新了该行,则把事务ID赋给row trx_id
==> 既: row trx_id = 最新更新该行的事务ID
7.数据版本的可见性规则: read - view 和 row trx_id 对比得出.
疑问1: 3.b的具体场景是什么样的? ==> 图3画的不对.
总结1 事务视图(一致性读) :
1. 版本未提交, 不可见.
2. 版本已提交, 但是在视图创建后提交的, 不可见;
3. 版本已提交, 是在视图创建前提交的, 可见.
4.自己的更新, 可见.
4. 事务A查询数据逻辑图
总结2: select 是一致性读:
三: 更新逻辑
事务B更新逻辑
规则1: 更新数据都是先读后写, 这个读就是当前读 current read
适用范围: update 语句 , 加锁的select 语句
6.事务C不是马上提交
推导1 : 如果事务C不马上提交, 则需要用到两阶段锁协议, 事务B的update 和select 会被阻塞.
总结3:update 是当前读.
疑问2: 那insert 和delete 呢 ?
7. 事务B更新逻辑图
结论4: 可重复读的核心是一致性读 consistent read
四: 可重复读 和 读提交的区别:
可重复读: 事务开始时创建一致性视图;
读提交: 每一个语句执行前,重新算一个新视图.
网友评论