第六篇：并发-粒度锁

目录

并发事务 – 冲突和性能问题

锁的粒度

实践中的实际粒度锁

隔离概念...树锁定和意图锁定模式

乐观锁

时间戳

---

并发事务 – 冲突和性能问题

多个并发运行的事务可能会导致冲突
- 我们仍然尽量允许并发运行以获得更好的性能，同时尽可能避免冲突

一个新的解决方案：
使用粒度锁——我们需要建立一些层次结构，然后可以在任何级别上获取锁，这将自动授予其后代锁。

锁的粒度

主意：
选择一组列值（谓词）。
它们形成图/树结构。
锁定此图/树中的节点

它允许锁定整个数据库、整个文件或仅一个键值。

锁定整个数据库——冲突较少，但性能较差
在单个记录级别锁定 - 更多的锁，更好的性能

我们如何允许两种粒度？
意图模式锁定粗颗粒。
+ 授予
- 延迟

实践中的实际粒度锁

X	eXclusive lock 排他锁
S	Shared lock 共享锁
U	Update lock - 意图以后更新
IS	Intent to set Shared locks at finer granularity意图以更细的粒度设置共享锁
IX	Intent to set shared or eXclusive locks at finer granularity 意图以更细的粒度设置共享或排他锁
SIX	a coarse granularity Shared lock with an Intent to set finer granularity eXclusive locks粗粒度共享锁，意图设置更细粒度的排他锁

从根到叶获得锁。
从叶子到根释放锁。

IS：打算设置更精细的S锁
IX：打算设置更精细的 S 或 X 锁
SIX：S+IX

要在非根节点上获取 S 模式或 IS 模式锁，一个父节点必须处于 IS 模式或更高模式（{IS,IX,S,SIX,U,X} 之一）。
要在非根节点上获取 X、U、SIX 或 IX 模式锁，所有父节点必须保持在 IX 模式或更高模式（{IX,SIX,U,X} 之一）。

隔离概念...
树锁定和意图锁定模式

None ：不锁定所有请求。
IS（意图拥有更精细级别的共享锁）允许更细粒度的 IS 和 S 模式锁，并防止其他人在此节点上持有 X。
IX（意图在更精细的级别拥有排他锁）允许以更精细的粒度设置 IS、IX、S、SIX、U 和 X 模式锁，并防止其他人在此节点上持有 S、SIX、X、U。
S (shared ) 允许更细粒度的节点及其后代的读取权限，并防止其他人在此节点上持有 IX、X、SIX。

SIX（共享和意图独占）允许像在 IS 中一样读取节点及其后代，并防止其他人在此节点或其后代上持有 X、U、IX、SIX、S，但允许持有者 IX、U 和 X 模式锁定在 粒度更细。 SIX = S + IX
U（更新锁）允许读取节点及其后代，并防止其他人在该节点或其后代上持有 X、U、SIX、IX 和 IS 锁。
X（排他锁）允许写入节点并防止其他人在此节点及其所有后代上持有 X、U、S、SIX、IX 锁。

粒度锁的兼容模式

 

乐观锁

当冲突很少时，事务可以在不管理锁和等待锁的情况下执行操作——更高的吞吐量

- 使用无锁数据
- 在提交之前，每个事务都会验证没有其他事务修改了数据（通过采取适当的锁）——锁的持续时间很短
- 如果发现任何冲突，事务将重复尝试
- 如果没有冲突，进行更改并提交

时间戳

这些是乐观并发控制的特例。 在提交时，检查时间戳。 如果时间戳比事务读取时间更新，则事务中止。

时域版本控制

数据永远不会被覆盖，更新时会创建新版本。

<o,<V1, [t1, t2)>, <V2, [t2,t3)>, <V3,[t3,*)>

在提交时，系统验证所有事务的更新并将更新写入持久媒体。 这种计算模型统一了并发、恢复和时域寻址。

T1
select average (salary)
from employee

T2
update employee
set salary = salary*1.1
where salary < $40000

如果事务 T1 首先开始并持有工资 < $40000 的员工记录的读锁，则 T2 将延迟到 T1 完成。 但是使用时间戳 T2 不必等待 T1 完成！

ok，今天内容比较少，后续会提供更详细的解释，辛苦大家观看！