今天突然有人问我，一个常见的SELECT操作，会产生具体哪些锁？

于是做了下测试。

测试环境如下：

环境一：SQL SERVER 2005 SP3(64位)

环境二：SQL  SERVER 2008 R2 （64位）

使用到的脚本如下：

SELECT request_session_id,resource_type, resource_associated_entity_id,
request_status, request_mode,
resource_description, p.object_id,object_name(p.object_id) as object_name, p.*
FROM sys.dm_tran_locks left join sys.partitions p
on sys.dm_tran_locks.resource_associated_entity_id = p.hobt_id
WHERE resource_database_id = db_id('AdventureWorks')
order by request_session_id, resource_type, resource_associated_entity_id

打开

set transaction isolation level REPEATABLE READ
go
set statistics profile on
go

设置。

使用微软自带的AdventureWorks数据库的Employee表做测试，测试前，删除多余的索引，只保留聚集索引。

运行一个简单的查询：

begin tran
select EmployeeId, LoginID, Title
from  HumanResources.Employee
where EmployeeId in (3, 30, 200)

在SQL SERVER 2005环境下

查询结果如下：

查询后保留的锁信息：

连续持有的锁有：

1.因为连接正在访问数据库AdventureWorks，所以它在数据库一级加了一个共享锁，以防止别人将数据库删除。

2.因为正在访问表格Employee，所以在表格上家了一个意向共享锁，以防止别人修改表的定义。

3.查询有3条记录返回，所以在这3条记录所在的聚集索引键上，分别持有一个意向共享锁。

在SQL SERVER 2008R2环境下的锁信息：

发现二者之间还是有区别的。

在SQL SERVER 2008 R2版本中，

多了一个对METADATA资源的架构锁 Sch-S 。

可以说，这个查询锁的数目是很少的。其他用户访问同一张表，只要不妨问这3条记录，就不会被影响到。

SQL2008R2 select执行计划.jpg

SQL2005SP3 select后保留的锁.jpg

SQL2008R2 select后保留的锁.jpg