意向锁

本文的原文

SQL Server里的锁层级

当你读取一条记录时，SQL Server默认请求一个共享锁（S），当你修改一条记录时，SQL Server请求一个排它锁（X）。这2个锁彼此不兼容，当你同时向读写一条记录时，会发生阻塞。

另外对于行级别的锁，在锁层级里，SQL Server也会在更高一层请求所谓的意向锁（Intent Locks）：在页和表层级。SQL Server基于请求的行级别锁，请求下列的意向锁：

意向共享锁（Intent Shared Lock (IS)），当你在行层级有一个共享锁（S）
意向更新锁（Intent Update Lock (IU)），当你在行层级有一个更新锁（U）
意向排它锁（Intent Exclusive Lock (IX)），当你在行层级有一个排它锁（X）

因此当读或写你记录时，你总会获得如上图所示的锁层级。当SQL Server为什么使用这些意向锁呢？

SQL Server里的意向锁

从技术上来说，SQL Server并不真的需要意向锁。这和性能优化有关。我们来具体看下。有了意向锁，SQL Server表明在锁层级里更高层级上，你需要请求其他锁。意向共享锁（Intent Shared Lock）告诉SQL Server某个地方有共享锁（S）。对于意向更新锁（Intent Update Lock）或意向排它锁（Intent Exclusive Lock）也是一样，但这次SQL Server知道在某个地方有更新锁（Update Lock）或排它锁（Exclusive Lock）。这只是个标识，没别的。

但这个标识怎么帮助SQL Server性能优化？假设你再表层级请求一个排它锁（X）。在这个情况下，SQL Server需要知道在某个记录上是否有不兼容的锁（像共享锁（S）或更新锁（U））。没有意向锁，SQL Server需要检查每条记录来看是否有一个授予的不兼容锁。

但在表层级有意向共享锁（IS）的话，SQL Server马上知道在某个地方有授予的共享锁（S），因此在表层级不能请求排它锁（X）。这个就是SQL Server里存在意向锁的原因：在锁层级里，如果某个地方有不兼容的锁存在，可以让SQL Server快速查到。很简单，是不是？

举个例子吧：

CREATE TABLE TEST1(C1 VARCHAR(100),C2 VARCHAR(100),C3 VARCHAR(100)) 
insert into 
select newid(),newid(),newid()
--因为S锁在查询结束后就会自动释放，不管是否在事务中，查询语句加上HOLDLOCK可以将S锁持续到事务提交
BEGIN TRAN

SELECT * FROM TEST WITH(HOLDLOCK) where C1 ='9CDF55AC-18FA-4685-9227-9A16B224CA89'

打开另外一个会话

SELECT 
    resource_type,
    request_mode,
    resource_description,
    request_session_id,
    request_status,
    resource_associated_entity_id,
    DB_NAME(resource_database_id)as resource_database
FROM
    sys.dm_tran_locks
WHERE
    resource_type <> 'DATABASE' AND DB_NAME(resource_database_id)='CustomDB'
ORDER BY
    request_session_id;

得到如下图，page和object上面全部都是意向共享锁，标识区域其实是object的object_id，可以使用object_name(object_id) 查看，其实就是表 TEST1

小结

技术上，SQL Server不需要意向锁，因为它只表示在锁层级里，某个地方有一些其他特定类型的锁。当基于如果你想在页或表上请求特定的锁，SQL Server可以更高效的检查是否有不兼容的锁存在，还是需要有意向锁。

老外的原文：

原文链接：

https://www.sqlpassion.at/archive/2016/05/16/why-do-we-need-intent-locks-in-sql-server/