DBPA · 12.3

封锁粒度、意向锁与多版本并发控制

比较锁粒度、意向锁和版本控制的并发取舍

VER. 2608.3 Built with impress.js

学习目标

完成本节后，你应该能够

01比较不同封锁粒度的并发度和开销
02解释多粒度树中的显式锁和隐式锁
03说明 IS、IX、SIX 的意向语义
04判断意向锁请求的相容性
05描述 MVCC 如何减少读写阻塞
06比较封锁、时间戳、乐观方法和 MVCC 的控制点与代价

2/14

LEARNING OBJECTIVES

锁对象越大越易管理，也越容易造成阻塞

对象越小通常并发度越高，但前提是事务访问不同对象；锁管理成本也会增加

逻辑粒度：数据库→关系→元组→属性值物理粒度：页、物理记录（页属于物理粒度，不是关系与元组之间必然存在的逻辑层级）

3/14

LOCK GRANULARITY

访问范围决定合适粒度

同一批事务在不同粒度下会有不同等待关系

场景	合适粒度	主要判断
`T1` 修改 `L1`，`T2` 修改同页 `L2`	页级／元组级	页级使 `T2` 等待；元组级允许并发但锁更多
`T3` 读取整张表	关系或数据库	避免逐元组申请大量锁
事务只修改少量元组	元组级	减少不相关数据被一起阻塞

Takeaway

粒度选择同时看访问范围、并发度与锁管理开销；小粒度的优势取决于事务访问范围

4/14

GRANULARITY TRADEOFF

显式锁和隐式锁来自不同层级的申请

多粒度协议允许节点独立申请，但祖先锁会把保护传播到后裔

S(R1)→L1、L2 获得隐式 S 保护 IX(R1)→只声明后裔将申请 X，不等于已获得 X(L1)

Takeaway

直接申请的是显式锁；祖先 S/X 形成隐式保护；IS/IX 只声明后裔的加锁意图

5/14

MULTI-GRANULARITY

意向锁让系统在上层快速发现下层冲突

申请元组锁前先向祖先节点声明意图

IS

IS 表示后裔节点准备加 S 锁

IX

IX 表示后裔节点准备加 X 锁

SIX

SIX 表示当前节点加 S 锁并带有 IX 意图，即 SIX = S + IX

Takeaway

纵轴是已持有锁，横轴是请求锁；Y 表示相容，N 表示不相容并需等待。例：IS 与 IX 相容，SIX 与 IX 不相容；申请更强的锁可以替代较弱的保护，反向替代可能不安全

6/14

INTENTION LOCKS

多粒度加锁自上而下，释放自下而上

意向锁把后裔的潜在冲突汇总到祖先，并把层级检查变成可执行顺序

IX(DB)→IX(R1)→X(L1)→UNLOCK L1→UNLOCK R1→UNLOCK DB

01目标节点若有祖先，从最上层祖先开始逐级申请相应意向锁；目标是根节点时无需额外祖先锁
02到目标页或元组申请 S 或 X 锁
03释放锁时从目标向根反向进行
04这条层级顺序还要同时满足 2PL 的扩展／收缩边界

7/14

INTENTION ORDER

封锁之外的并发控制路线

封锁在申请 S/X 锁时处理冲突；其他路线把处理点移到时间戳、提交验证或版本读取

方法	控制点	直观特点
封锁	申请 `S/X` 锁时	冲突时等待或回滚
时间戳	冲突规则判定时	违规事务回滚并重新开始
乐观方法	提交前验证	平时少管制，验证失败则回滚
MVCC	读写访问与版本	用旧版本减少读写直接阻塞，但增加存储和检查

8/14

OTHER METHODS

MVCC：读取旧版本，提交仍需检查

T1 写出 Q2；T2 读取 Q1；T2 在提交前检查 T1 状态

读路径

T2 读取符合快照条件的 Q1，在旧版本上继续执行；图中虚线表示提交检查／事务关系，不表示 T2 读取 Q2

提交边界

事务状态检查不等同于 c1 的乐观方法验证；T1 未完成时，T2 仍可能等待后再提交

9/14

MVCC

版本时间戳：选可见版本，拒绝过晚写入

读按版本链选择可见版本，写按 R-timestamp 检查；每个版本还要记录读写时间戳

判定	示例	结果
`W-timestamp(Qk)`	成功写入 `Qk` 的最大事务时间戳	读 `TS(T)=15` 时选最新的 `W≤15` 版本
`R-timestamp(Qk)`	成功读取 `Qk` 的最大事务时间戳	写入 `TS(T)=15` 且 `R-timestamp=20` 时属于过晚写入
读规则	`W(Q1)=10`，`W(Q2)=20`，`TS(T)=15`	读取 `Q1`，而不是尚未可见的 `Q2`
写规则	`TS(T)<R-timestamp(Qk)`；`TS(T)=W-timestamp(Qk)`；否则	依次回滚、覆盖、创建新版本

10/14

VERSION EVIDENCE

MV2PL：多版本读取与提交验证

读可继续；更新提交前在 X 锁对象上申请验证锁 C

01

生成

更新事务 T1 产生新版本

02

验证

T1 在持有 X 锁的对象上申请 C 锁

03

等待

C 与 S 不相容，等待读者释放 S 锁

04

替换

获得 C 锁后替换并清理不再需要的旧版本

05

提交

释放 C 锁并完成事务提交

Takeaway

MV2PL 中 S 与 X 可相容，但 C 与 S/X 都不相容；C 锁只在提交边界出现，所以更新事务仍可能等待读事务，MV2PL 不是“所有读写都无等待”

11/14

MV2PL

本节回顾

按访问范围、层级声明和版本规则选择并发控制方案

粒度

T1/L1 与 T2/L2 不冲突时，元组级允许并发；T3 读整表时，大粒度减少锁管理开销

意向

祖先 S/X 提供隐式保护，IS/IX 声明后裔意向；按 IX(DB)→IX(R1)→X(L1) 申请

多版本

T1 写 Q2、T2 读 Q1；系统按时间戳选版本并检查提交边界

选择

MV2PL = 多版本读取 + 更新事务 2PL + C 锁验证；它减少读写直接阻塞，但仍有等待和存储成本

Takeaway

S/X 锁提供基本互斥，2PL 约束申请与释放；粒度、意向锁、MVCC 和 MV2PL 扩展并发控制选择

12/14

RECAP

本节知识地图

13/14

KNOWLEDGE MAP

本节问题

01T1 修改 L1、T2 修改同页 L2、T3 读取整表时，如何选择粒度，为什么？
02S(R1)、IX(R1)、SIX(R1) 如何形成保护？IX(R1) 是否等于 X(L1)？不相容时请求方怎样处理？
03为 X(L1) 写出从数据库到目标元组的申请序列和反向释放序列，并说明 2PL 边界？
04W(Q1)=10、W(Q2)=20、R-timestamp(Q1)=20、TS(T)=15 时读哪个版本？写 Q1 是否回滚？
05MV2PL 中更新事务为何可能在 C 锁处等待读事务？MVCC 减少哪种直接阻塞？

14/14

CHECK YOUR UNDERSTANDING