1 RR 级别 , 事务启动的时候会创建 read view
2 事务要更新一行 , 被其他锁住了 , 会等待
3 这个时候读到的值是?
4 RR事务在执行第一条语句才真正启动 (第一个快照读语句)
5 如果要马上启动 , 用 start transaction with consistent snapshot
6 有两种”视图”概念
7 一是 view , 用 create view 创建的虚拟表
8 另一个是 innodb 内置的一致性读用的视图 , 实现 RC 和 RR 的隔离级别用
9 知识点 8 的视图定义的是 这个事务能看到什么数据
10 RR 基本的快照是基于整库的 , 但只有在发送了修改的时候才会创建 read view
11 每个事务都有 transaction id 严格递增
12 每行数据的多个版本都有关联 transaction id 叫做 row_trx_id
13 语句更新会生成 undo log , 用于回滚
14 对 undo log 不太熟悉 , 前面少看了什么吗
15 undo log就是表中的虚线 U1 U2 U3
16 v1 v2 v3物理上并不存在 , 是通过当前值 V4 通过 undo log 计算的
17 当前事务如果要看到他的版本 , 就需要从 V4 一直往回找 , 找到 trx_id 相等的取出来
18 根据当前事务生成的事务ID集合
19 在视图创建之前提交的 , 则可见
20 RR 级别下 , 如果是更新的话 , 都是当前读,而不是一致性读 , 否则会发生丢失修改
21 更新后添加了新的视图,事务 id 也和自己一致 , 因此一致性读就改变了
22 select 加锁的话也是当前读
23 lock in share mode 读锁 共享锁
24 for update 写锁 排他锁
25 如果 update 没提交 , 由于两阶段锁协议 , 数据上的写锁还没释放 , 其他 update 和 select 会被阻塞 , 释放后才能当前读
26 RR 的核心就是一致性读
27 但是更新的时候只能读当前读 , 如果被其他事务锁住 , 只能等
28 也就是 RR 同样有可能加锁 , 更新的时候
29 RC 在每个语句执行前计算新的视图 , 而 RR 是公用一个一致性视图
30 一道 RC 的情况分析 , A 和 B 获取到的 k 是多少
31 RR 普通查询是一致性的 , 根据 row_trx_id 回溯查找对应的视图
32 表结构不支持 RR , 因为表结构没有对应的行数据 , 没视图
33 mysql 8 之后可能支持
34 一道思考题
35 思考题解答
第一种情况
1 另一个事务修改并提交了
2 当前事务的一条修改 , 读取的是当前读 , 但是没有匹配的数据 , 所以没有修改任何数据 , 也没有生成新的视图
3 因此当再次select的时候还是事务开始的时候select的视图
4 这个思考题可以作为在项目中遇到的难点
第二种情况 , 先不看了 , B不属于活跃的事务, 归类到未提交的事务里了
业务中想绕过这种问题的话 , 用乐观锁
