SQL封锁

封锁粒度是指封锁对象的大小范围。 封锁对象可以涵盖整个数据库，也可以细化到某个属性值。 例如，可以对整个数据库进行封锁，也可以对特定属性值进行封锁。 封锁对象的大小被称为封锁粒度。 多粒度封锁允许系统同时支持多种封锁粒度，从而为不同的事务提供灵活的选择。

三级封锁协议的主要区别 锁的粒度 请求封锁的时机 持有封锁的时间 需要申请封锁的操作 读操作（共享锁） 写操作（排它锁） 释放锁的时机 事务提交或回滚

顺序封锁是一种在SQL数据库系统中常见的并发控制策略，它预先规定了数据对象的封锁顺序，所有事务均按此顺序执行封锁。然而，顺序封锁策略面临着高昂的维护成本和动态变化的数据对象挑战，例如数据的插入和删除操作会使得封锁顺序难以长期稳定。此外，事务在执行过程中动态决定封锁请求，进一步增加了实施顺序封锁的复杂性。

在SQL并发控制中，事务T在修改数据R之前需先加X锁，并在事务结束时释放。一级封锁协议确保了修改的数据不会丢失，尽管它不能保证可重复读和避免读取“脏”数据。

封锁机制的操作单位其实讲白了就是“你锁多大一块数据”。数据库的锁分粗细，锁得越细，资源并发越高，但开销也大。嗯，这一篇讲的就是这个话题——封锁粒度。 数据库的封锁对象分两种：逻辑单元和物理单元。逻辑上比如属性值、元组、整张表，物理上就是页、记录这些更底层的东西。一般你写业务 SQL 不太碰得上物理级，但搞性能调优时就躲不了。 像 S 锁（共享锁）和 X 锁（排它锁）都是锁在某个具体的数据对象上的。举个例子，查一条订单详情，加个 S 锁 防止别人改；改用户余额，加 X 锁 防止脏数据。 锁粒度小，比如锁行、锁列，效率高并发也高，但锁的管理成本也更高。反过来，锁整表、锁页，对并发不友好，但实现简单

在处理SQL并发控制中的脏数据时，使用封锁机制是一种有效的方法。例如，事务T1在修改C之前会对A加上X锁，确保其他事务如T2在请求C的S锁时被拒绝，从而避免T2读取到脏数据。即使T1撤销后，C的值恢复为100，T2在等待T1释放锁之后再读取C的值，仍然可以确保数据的一致性。这种方法有效地解决了并发操作中的数据安全问题。

封锁机制是并发控制的核心手段；在事务对数据对象操作前，先请求系统对其加锁；加锁后，事务对数据对象具有控制权，直到释放锁之前，其他事务无法更新该数据对象。

想要深入了解Oracle的锁机制？这篇文章足以满足你的需求。不信，只需阅读，即可发现，我看了这篇文章后，受益良多。

多粒度封锁（续）例：三级粒度树。根结点为数据库，数据库的子结点为关系，关系的子结点为元组。数据库关系Rn关系R1元组元组……

多粒度封锁协议允许对树结构中的每个节点进行独立加锁。对某一节点加锁将影响其所有子节点，这种封锁方式包括显式和隐式两种类型。