为什么我们需要意图锁定？

Question

在数据库中，我们不希望在修改该表中的一行时删除该表。根据我的理解，在表中写入一行时，表上的读锁+行上的写锁应该足够了(基于在删除表时需要写锁)，为什么在这种情况下我们需要意向锁？似乎很多数据库使用意图锁定，这让我非常困惑。我认为pthread_rwlock应该足够了。

Answer 1

今天的结论之一是“意图锁可以以更廉价/更安全的方式锁定父节点及其所有子节点的只读模式”。

以使表只读为例，如何将其锁定为S模式？

1. 我们将表锁在S模式下，用户仍然可以用S(表)+W(行)的方式修改行。为了避免这种情况，我们需要在S模式下锁定每一行，以确保行不会被更新。代价如此之大，而且它有一个bug，用户也可以插入新的行。-费用太高，而且不安全
2. 我们以X模式锁定表，其他人如何读取行(表上的S+行上的S)，没有办法，因为表上的mode_X阻塞了表上的MODE_S。这可不是只读的。

使用意图锁的正确解决方案是：

把桌子锁在MODE_S里，仅此而已！

任何修改行的意图都需要在表上使用一个MODE_IX锁，但是它被MODE_S阻止了。这个解决方案是廉价/高效和安全的！

Answer 2

我读过这里，它们只存在于性能上。假设您想要删除一个表，但是您必须检查每一行是否已锁定--这将耗费时间，而且您必须锁定所检查的每一行。

以下是博客文章中的引文：

从技术角度来看，Server并不真正需要意图锁定。它们与性能优化有关。让我们更详细地看一看。出于意图，Lock SQL Server只是在锁层次结构中的更高级别表明您已经在其他地方获得了一个锁。一个意图共享锁告诉Server，在其他地方有一个共享锁。意向更新或意向独占锁定也是如此，但这一次Server知道某个地方存在更新锁或独占锁。这只是一个暗示，仅此而已。 但是，这一指示如何帮助Server进行性能优化？假设您想在表级别获得一个独占锁。在这种情况下，Server必须知道记录上是否存在不兼容的锁(比如共享锁或更新锁)。如果没有意图，SQL Server将必须检查每条记录，以查看是否授予了不兼容的锁。 但是，为了在表级别上具有共享锁的意图，SQL Server立即知道共享锁已在其他地方授予，因此不能在表级别授予独占锁。这就是为什么在Server中存在意图锁的全部原因:允许有效检查锁层次结构中是否存在不兼容的锁。很容易，不是吗？

Answer 3

表上的读锁+行上的写锁

这将破坏表上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使用。

可以找到锁兼容性表，例如在维基上。