锁不住的查询

最近在处理一个锁的问题时，发现一个比较郁闷的事，使用X锁居然无法锁住查询，模拟这个问题，可以使用如下T-SQL脚本来建立测试环境。

USE master;
GO
IF @@TRANCOUNT > 0
ROLLBACK TRAN;
GO
-- =======================================
-- 建立测试数据库
-- a. 删除测试库, 如果已经存在的话
IF DB_ID(N'db_xlock_test') IS NOT NULL
BEGIN;
ALTER DATABASE db_xlock_test
SET SINGLE_USER
WITH
ROLLBACK AFTER 0;
DROP DATABASE db_xlock_test;
END;
-- b. 建立测试数据库
CREATE DATABASE db_xlock_test;
-- c. 关闭READ_COMMITTED_SNAPSHOT 以保持SELECT 的默认加锁模式
ALTER DATABASE db_xlock_test
SET READ_COMMITTED_SNAPSHOT OFF;
GO
-- =======================================
-- 建立测试表
USE db_xlock_test;
GO
CREATE TABLE dbo.tb(
id int IDENTITY
PRIMARY KEY,
name sysname
);
INSERT dbo.tb
SELECT TOP(50000)
O1.name + N'.' + O2.name + N'.' + O3.name
FROM sys.objects O1 WITH(NOLOCK),
sys.objects O2 WITH(NOLOCK),
sys.objects O3 WITH(NOLOCK);
GO

然后，建立一个连接，执行下面的脚本来实现加锁。

-- =======================================
-- 测试连接1 - 加锁
BEGIN TRAN
--测试的初衷是通过SELECT加锁，结果发现UPDATE也锁不住
UPDATE dbo.tb SET name = name
--SELECT COUNT(*) FROM dbo.tb WITH(XLOCK)
WHERE id <= 2;
SELECT
spid = @@SPID,
tran_count = @@TRANCOUNT,
database_name = DB_NAME(),
object_id = OBJECT_ID(N'dbo.tb', N'Table');
-- 显示锁
EXEC sp_lock@@SPID;

通过执行结果，可以看到对象被加锁的情况：表级和页级上是IX锁，记录上是X锁。

然后新建一个连接，执行下面的T-SQL查询，看看会否被连接1锁住

-- =======================================
-- 测试连接2 - 被阻塞(在测试连接1 执行后执行)
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SELECT * FROM dbo.tb
WHERE id <= 2;

上述查询会很快返回结果，并不会被查询1阻塞住。

按照我们的了解（联机帮助上也有说明），在READ COMMITTED事务隔离级别下，查询使用共享锁（S），而根据锁的兼容级别，S锁是与X锁冲突的，所以正常情况下，连接2的查询需要等待连接1执行完成。可是测试的结果去违反了这一原则。

为了了解为什么连接2不会被阻塞，对连接2做了一个Trace，发现一个更郁闷的问题，Trace的结果如下：

Trace的前面两行是连接2的Trace结果，从结果看，连接2仅使用了意向共享锁（IS），而且只是表级和页级，按照锁的兼容性原则，IS和IX（连接1在表级和页级仅使用了IX锁）是不冲突的，所以连接2的查询不会被阻塞。在增加了查询的数据量后，Trace结果表明查还是只在表级和页级使用了IS锁（Trace结果的最后4行）。

对于这个问题，解决的办法当然就是提升连接1锁的粒度，使用PAGLOCK表提示将锁的粒度提升到页级，这样IS与X是冲突的，就可以成功阻塞连接2。

但疑问就是，为什么查询只在表级和页级下意向共享锁（IS），而不在行级下共享锁（X），这个似乎与联机帮助上的说明不一样（还是一直以来理解上的偏差呢）。

附：联机帮助上关于锁模式的说明

• < 上一篇

  通过mysql判断点是否在指定多边形区域内

• 下一篇 >

  讲解更新锁（U）与排它锁（X）的相关知识