在数据库中，我们不希望在修改此表中的行时删除该表。根据我的理解，当在表中写一行时，表上的读锁定+行上的写锁应该就足够了（基于在删除表时需要写锁），为什么在这种情况下我们需要一个意图锁？似乎很多使用意图锁的数据库让我非常困惑。我认为pthread_rwlock应该足够了。
答案 0 :(得分：4)
我读过here他们只是为了表现而存在。想象一下，你想要删除一个表，但是你必须检查每一行是否锁定 - 这将是非常耗时的，你必须锁定你检查过的每一行。
来自博客文章的引文：
从技术角度来看，目前并不需要Intent Locks SQL Server。它们与性能优化有关。让我们 更详细地看一下。使用Intent Lock SQL Server 表示您在Lock Hierarchy中的更高级别 在其他地方获得了一把锁。 Intent Shared Lock告诉SQL Server 其他地方有一个共享锁。意图更新或意图 Exclusive Lock也是如此，但这次SQL Server知道这一点 在某个地方有一个Update Lock或Exclusive Lock。这只是一个 指示，仅此而已。
但该指示如何帮助SQL Server提高性能 优化？想象一下，你想获得一个独家锁 表级别。在这种情况下，SQL Server必须知道是否存在 在其他地方的不兼容的锁（如共享或更新锁） 记录。没有Intent Locks SQL Server必须检查每一个 记录以查看是否已授予不兼容的锁。
但是在表级别使用Intent Shared Lock，SQL Server知道 立即在其他地方授予了共享锁，并且 因此，不能在表级授予独占锁。 这就是为什么SQL Server中存在Intent Locks的全部原因：允许 高效检查是否存在不兼容的锁 锁定层次结构。很简单，不是吗？
答案 1 :(得分：0)
读取表上的锁定+行上的写锁定
这会破坏表格中read lock的含义。
假设并发SELECT操作，在执行期间需要未修改的表。此操作将在表格中读锁定 ...在您的实施中成功。这很糟糕，因为在行修改期间实际修改了表。
相反，跟随锁组合用于表中的修改行：
IX(Intent eXclusive) on table + X(eXclusive, similar to "write lock") on row
此组合兼容（即可以同时执行）并修改另一行，但不兼容与
S(Share, similar to "read lock") on table
使用SELECT。
可以在wiki上找到锁兼容性表。
答案 2 :(得分：0)
今天的结论之一是“ 意图锁可以以便宜/安全的方式以只读模式锁定父节点及其所有子节点”。
以使表为只读的情况为例，如何将其锁定为S-X模式？
我们将表锁定为S模式，然后用户仍然可以使用S（table）+ W（row）方式修改行。为了避免这种情况，我们需要以S模式锁定每一行，以确保不会更新行。代价是巨大的，并且有一个错误，用户也可以插入新行。 -价格太高，并不安全。
我们将表锁定为X模式，其他人如何读取行（表上的S +行上的S），这是没有办法的，因为表上的mode_X阻止了表上的MODE_S。那不是只读的。
使用意图锁的正确解决方案是：
在MODE_S中锁定表。就这样！
任何要修改行的意图都需要对表进行MODE_IX锁定，但是它被MODE_S阻止。该解决方案便宜/高效且安全！