KingbaseES锁

监控锁

锁是防止访问同一资源的事务之间进行破坏性交互的机制。资源可以是用户对象，例如表和行，也可以是用户不可见的系统对象，例如内存中的共享数据结构和数据字典行。

KingbaseES 数据库在执行 SQL 语句时会自动获取并管理必要的锁，因此您无需关心这些细节。但是，数据库还允许您手动锁定数据。

当两个或更多用户正在等待彼此锁定的数据时，可能会发生死锁。死锁会阻止某些事务继续工作。KingbaseES 数据库自动检测死锁情况并通过回滚死锁中涉及的一条语句来解决它们，从而释放一组冲突的行锁。

KingbaseES 数据库旨在避免死锁，它们并不常见。大多数情况下，它们发生在事务显式覆盖数据库的默认锁定时。死锁会影响数据库的性能，因此 KingbaseES 提供了一些脚本和视图，使您能够监控锁。

使用 sys_locks ¶

所有活动事务持有的监控锁的基本配置即为系统视图 sys_locks。这个视图为每个可加锁的对象、已请求的锁模式和相关事务包含一行记录。

test=# select * from sys_locks;
-[ RECORD 1 ]------+----------------
locktype           | relation
database           | 16384
relation           | 12168
page               |
tuple              |
virtualxid         |
transactionid      |
classid            |
objid              |
objsubid           |
virtualtransaction | 3/744
pid                | 224515
mode               | AccessShareLock
granted            | t
fastpath           | t

监控死锁 ¶

显式锁定的使用可能会增加死锁的可能性，死锁是指两个（或多个）事务相互持有对方想要的锁。

例如，如果事务 1 在表 A 上获得一个排他锁，同时试图获取一个在表 B 上的排他锁， 而事务 2 已经持有表 B 的排他锁，同时却正在请求表 A 上的一个排他锁，那么两个事务就都不能进行下去。KingbaseES 能够自动检测到死锁情况 并且会通过中断其中一个事务从而允许其它事务完成来解决这个问题（具体哪个事务会被中 断是很难预测的，而且也不应该依靠这样的预测）。

要注意死锁也可能会作为行级锁的结果而发生（并且因此，它们即使在没有使用显式锁定的情况下也会发生)。考虑如下情况，两个并发事务在修改一个表。第一个事务执行：

UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 11111;

这样就在指定帐号的行上获得了一个行级锁。然后，第二个事务执行：

UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 22222;
UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 11111;

第一个 UPDATE 语句成功地在指定行上获得了一个行级锁，因此它成功更新了该行。 但是第 二个 UPDATE 语句发现它试图更新的行已经被锁住了，因此它等待持有该锁的事务结束。事 务二现在就在等待事务一结束，然后再继续执行。现在，事务一执行：

UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 22222;

事务一试图在指定行上获得一个行级锁，但是它得不到：事务二已经持有了这样的锁。所以 它要等待事务二完成。因此，事务一被事务二阻塞，而事务二也被事务一阻塞：一个死锁。 KingbaseES 将检测这样的情况并中断其中一个事务。