神秘的 SIX 锁，第 1 部分

核心提示： 解决难题现在，我们来看看表级 S 锁并应用这些规则，神秘的 SIX 锁，第 1 部分(4)，S 锁向其他用户表明我的应用程序没有低级（页级）S 锁，表级的 IX 锁会告诉其他用户我有低级的 X 页锁，在我的下一篇专栏文章中，我们将再次扮演侦探，我不能在这一个实体上有两个锁（规则 1），因此

解决难题

现在，我们来看看表级 S 锁并应用这些规则。S 锁向其他用户表明我的应用程序没有低级（页级）S 锁。表级的 IX 锁会告诉其他用户我有低级的 X 页锁。我不能在这一个实体上有两个锁（规则 1）。因此，必须判断哪个锁的限制更严（规则 2）。选择的锁还必须报告可能存在的任何低级锁（规则 3）。在这种非常特殊的情况下，S 锁和 IX 锁都不合适。它们都不满足规则 3 的要求。因此，在 S 锁和 IX 锁之间 “协商” 的结果是获得实体上的一个 SIX 锁。

SIX 锁的 S 部分告诉其他用户，我没有低级（页级）S 锁，但是我允许他们用 IS 锁执行读操作（我的 S 锁可以与其他用户的 IS 锁共存）。SIX 锁的 IX 部分告诉其他用户，我有低级的 X 页锁。他们应该知道，如果他们请求这个页上的 S 页锁，就可能遇到超时。

图 1. SQL 锁兼容性矩阵

所以，如果看一下 SQL 锁兼容性矩阵，就会发现我的 SIX 锁只与 IS 锁共享数据（图 1）。这正是我要的效果。

如果其他用户使用 IS/IS/S 锁协议在表中进行页级锁定，操作会成功。如果有人尝试在这三级上依次获得 IX/IX/X 锁，他会在表级被拒绝。如果有人尝试在前两级上发出 LOCK TABLE 语句并（以 eXclusive 模式）获得 IX/X 锁或（以 Share 模式）IS/S 锁，也会在表级被拒绝。通过使用 IX/SIX/X 协议，我的应用程序可以在不获得页锁的情况下执行读操作，还允许其他用户用 IS/IS/S 协议执行读操作，而且只在执行维护期间有页锁开销。

解释了一个神秘现象

我已经解释了 DB2 中的一个神秘现象。在我的下一篇专栏文章中，我们将再次扮演侦探，看看我们是否能够解开其他迷团。