ITPub博客

首页 > Linux操作系统 > Linux操作系统 > SQL SERVER中一个常见SELECT动作要申请的锁(-)

SQL SERVER中一个常见SELECT动作要申请的锁(-)

原创 Linux操作系统 作者:edwardking888 时间:2011-04-08 13:49:34 0 删除 编辑

今天突然有人问我,一个常见的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

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/8183550/viewspace-691944/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2010-04-03

  • 博文量
    477
  • 访问量
    1462047