为什么我们需要意图锁？

Question

在数据库中，我们不希望在修改表中的一行时删除该表。根据我的理解，在表中写行时对表的读锁和对行的写锁就足够了（基于在删除表时需要写锁），为什么在这种情况下需要意图锁？似乎许多使用意图锁的数据库使我非常困惑。我认为pthread_rwlock应该足够了。

Answer 1

我在这里读到它们只是为了性能而存在。想象一下，您想删除一个表，但您必须检查每一行是否已锁定 - 这将非常耗时，并且您必须锁定您检查的每一行。

这是博客文章中的引文：

从技术角度来看，SQL Server 并不真正需要意图锁。它们与性能优化有关。让我们更详细地了解一下。使用意图锁 SQL Server 只是在锁层次结构中的更高级别指示您已在其他地方获得了锁。意图共享锁告诉 SQL Server 在其他地方有共享锁。Intent Update 或 Intent Exclusive Lock 的作用相同，但这次 SQL Server 知道某处存在更新锁或排他锁。这只是一个提示，仅此而已。

但是该指示如何帮助 SQL Server 进行性能优化？假设您想在表级别获取排他锁。在这种情况下，SQL Server 必须知道记录上的其他地方是否存在不兼容的锁（如共享锁或更新锁）。如果没有意向锁，SQL Server 将不得不检查每条记录以查看是否授予了不兼容的锁。

但是使用表级别的意图共享锁，SQL Server 立即知道共享锁已被授予其他地方，因此无法在表级别授予排他锁。这就是 SQL Server 中存在意图锁的全部原因：允许有效检查锁层次结构中某处是否存在不兼容的锁。很容易，不是吗？

Answer 2

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

以将表设为只读的情况为例，如何在SX模式下锁定它？

1. 我们将表锁定在S模式下，然后用户仍然可以使用S(table) + W(row)方式修改行。为了避免这种情况，我们需要在 S 模式下锁定每一行，以确保行不会被更新。成本是如此之大，而且它有一个错误，用户也可以插入新行。——成本太高，而且不安全。

2. 我们将表锁定在 X 模式下，其他人如何读取行（表上的 S + 行上的 S），没办法，因为表上的 mode_X 阻塞了表上的 MODE_S。那不是只读的。

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

将表锁定在 MODE_S 中。就这样！

任何修改行的意图都需要在表上获取 MODE_IX 锁，但会被 MODE_S 阻止。该解决方案便宜/高效且安全！