Sql Server之旅——第十四站 深入的探讨锁机制

原文:Sql Server之旅——第十四站 深入的探讨锁机制

  上一篇我只是做了一个堆表让大家初步的认识到锁的痉挛状态,但是在现实世界上并没有这么简单的事情,起码我的表不会没有索引对吧,,,还

有就是我的表一定会有很多的连接过来,10:1的读写,很多码农可能都会遇到类似神乎其神的死锁,卡住,读不出来,插不进入等等神仙的事情导致性

能低下,这篇我们一起来探讨下。

 

一: 当select遇到性能低下的update会怎么样?

1. 还是使用原始的person表,插入6条数据,由于是4000字节,所以两条数据就是一个数据页,如下图:

1 DROP TABLE dbo.Person
2 CREATE TABLE Person(ID INT IDENTITY,NAME CHAR(4000) DEFAULT 'aaaaa')
3 --插入6条数据,刚好3个数据页
4 INSERT INTO dbo.Person DEFAULT VALUES
5 go 6

 

2. 为了模拟性能低下的Update操作,我们开个显式事务来更新ID=4的记录,并且用profile看一下,如下图:

1 BEGIN TRAN
2 UPDATE dbo.Person SET NAME='bbbbb' WHERE id=4

   

3. 然后我们开下另一个会话连接,读取ID=6的记录会是怎样????好奇吗????

1 SELECT * FROM Person WHERE ID=6

从上面流程你是否看到,当扫描到89号数据页的slot1槽位的时候卡住了。。。我想你应该知道update正好已经给这条记录加上了X锁。。。如果你

够细心,你还会发现,给S锁附加记录的条件是在当引擎发现记录所在的数据页已经附加上了IX锁的情况下,才给该号数据页下的每条记录附加S锁,

对吧。。。好了,既然在Profile上面看不到了,我还是有其他办法来判断到底select语句现在处于什么状态。

 

4. 使用sys.dm_tran_locks来看当前各个连接持有锁的状态。

1 SELECT  l.request_session_id,
2         DB_NAME(l.resource_database_id),OBJECT_NAME(p.object_id),
3         l.resource_description,l.request_type,
4         l.request_status,request_mode
5 FROM sys.dm_tran_locks AS l
6 LEFT JOIN sys.partitions AS p
7 ON l.resource_associated_entity_id=p.hobt_id

仔细观察上图可以看到,当前有51和52号会话,51号在1:89:1槽位上使用了X锁并且没有释放,52号此时也进入了1:89:1中,并且想给该

RowID附加S锁,但是你也知道S和X锁是排斥的,所以很无奈的一直保持等待状态。

 

二:使用索引或许可以帮你逃过一劫

  当你看完上面的讲叙,是不是有点害怕???要是在生产环境下出现了这种情况,那我们是不是死的很惨???那接下来使用索引是不是真

的可以帮我们躲过一劫呢???下面跟我一起看一看。

 

1. 新建索引index

1 -- 在ID列上建一个index
2 CREATE INDEX idx_person ON dbo.Person(ID)

 

2. 然后我们看下数据页的分布情况,可以看到下图中78,89,90是表数据页,93号为索引数据页。

1 DBCC TRACEON(2588,3604)
2 DBCC IND(Ctrip,Person,-1)

 

3. 麻蛋的,继续执行上面的那个慢update

BEGIN TRAN
UPDATE dbo.Person SET NAME='bbbbb' WHERE id=4

 

4. 激动人心的时刻来了,由于数据太少,所以我这里强制让引擎执行我创建的索引,看看结果怎样?

 

居然没卡住???现在是不是有一股强烈的好奇心来了,狗狗狗。。。马上开启profile,看看到底都发生了什么???

仔细看完这个图,是不是觉得很有意思呢???具体步骤如下:

第一步:给表(Object)加上IS锁。

第二步:因为要走索引,给93号索引数据页加上IS锁。

第三步:找到93号索引数据页的目标key,给这个key加上S锁,有人可能就会问了。。。这个key不就是6嘛,为什么这个key=(61005a25560e),

    你要是太好奇我可以告诉你,年轻人说话不要太屌,每行索引记录都有一个散列值,这个值就是根据索引的几个字段散列出来的,好处就是

        防止你的索引长度过大,导致锁这个记录的时候太耗费锁空间了。。。。如果你还是不太相信的话,我用DBCC给你看一看。      

            

第四步:根据这个key直接跳到存放记录的90号数据页中,万幸的是update的记录刚好不在90号数据页中。。。。就这样躲过一劫了。。。然

       后select顺利的读取到了该读的记录,最后释放相关的IS锁。

 

  如果你看懂了上面所说的几点,我想你对锁已经入门了,如果觉得还是有些糊涂的话,没关系。。。你有了profile利器,,,自己多试验试

验就好,毕竟我也是这样,晚上再发布最后一篇,明天晚上回家。。。这样就可以安心顺利的过大年了。

时间: 2024-10-03 19:07:28

Sql Server之旅——第十四站 深入的探讨锁机制的相关文章

Sql Server之旅——第十二站 sqltext的参数化处理

原文:Sql Server之旅--第十二站 sqltext的参数化处理   说到sql的参数化处理,我也是醉了,因为sql引擎真的是一个无比强大的系统,我们平时做系统的时候都会加上缓存,我想如果没有缓存,就不会有什么 大网站能跑的起来,而且大公司一般会在一个东西上做的比较用心,比较细,sqlserver同样也使用了缓存,其中就包括Data cache 和Plan cache两个大头. 现在我们也知道了Plan cache包括上一篇生成的xml结构和sql text,更有趣的是,sql text

Sql Server之旅——第十站 看看DML操作对索引的影响

原文:Sql Server之旅--第十站 看看DML操作对索引的影响 我们都知道建索引是需要谨慎的,当只有利大于弊的时候才适合建,我们也知道建索引是需要维护成本的,这个维护也就在于DML操作了, 下面我们具体看看到底DML对索引都有哪些内幕....   一:delete操作 现在我们已经知道,索引都是以B树的形式存在的,既然是B树,我们就要看看他们的叶子节点和分支结点,先准备点测试数据,如下图: CREATE TABLE Person(ID INT,NAME CHAR(200)) CREATE

Sql Server之旅——第十站 看看DML操作对索引的影响 

我们都知道建索引是需要谨慎的,当只有利大于弊的时候才适合建,我们也知道建索引是需要维护成本的,这个维护也就在于DML操作了, 下面我们具体看看到底DML对索引都有哪些内幕.... 一:delete操作 现在我们已经知道,索引都是以B树的形式存在的,既然是B树,我们就要看看他们的叶子节点和分支结点,先准备点测试数据,如下图: CREATE TABLE Person(ID INT,NAME CHAR(200)) CREATE INDEX idx_Name ON Person(NAME) DECLAR

Sql Server之旅——第四站 你必须知道的非聚集索引扫描

原文:Sql Server之旅--第四站 你必须知道的非聚集索引扫描 非聚集索引,这个是大家都非常熟悉的一个东西,有时候我们由于业务原因,sql写的非常复杂,需要join很多张表,然后就泪流满面了...这时候就 有DBA或者资深的开发给你看这个猥琐的sql,通过执行计划一分析...或许就看出了不该有的表扫描...万恶之源...然后给你在关键的字段加上非 聚集索引后...才发现提速比阿斯顿马丁还要快...那么一个问题来了,为什么非聚集索引能提速这么快...怎么做到的???是不是非常的好奇??? 这

Sql Server之旅——第十三站 对锁的初步认识

原文:Sql Server之旅--第十三站 对锁的初步认识 终于这个系列快结束了,马上又要过年了,没什么心情写博客...作为一个开发人员,锁机制也是我们程序员必须掌握的东西,很久之前 在学习锁的时候,都是教科书上怎么说,然后我怎么背,缺少一个工具让我们眼见为实...如果这样的话,学习一个东西就很容易忘记... 因为这些都是你背诵过来的...这篇的话我就来分享一个工具来帮助我们学习锁.   一:到底都有哪些锁 学习锁之前,必须要知道锁大概有几种???通常情况下作为码农我们只需知道如下几个锁即可..

Sql Server之旅——第二站 理解万恶的表扫描

原文:Sql Server之旅--第二站 理解万恶的表扫描 很久以前我们在写sql的时候,最怕的一件事情就是sql莫名奇妙的超级慢,慢的是撸一管子回来,那个小球还在一直转...这个着急也只有当事人才 明白,后来听说有个什么"评估执行计划",后来的后来才明白应该避免表扫描... 一:表扫描 1.现象 "表扫描"听起来很简单,不就是一行一行的扫嘛,你要说"执行计划"的话,我也会玩,为了更可观,我build一个表,再插入三行数据,如下图:   上面的P

Sql Server之旅——第一站 那些给我们带来福利的系统视图

原文:Sql Server之旅--第一站 那些给我们带来福利的系统视图 本来想这个系列写点什么好呢,后来想想大家作为程序员,用的最多的莫过于数据库了,但是事实上很多像我这样工作在一线的码农,对sql 都一知半解,别谈优化和对数据库底层的认识了,我也是这样...   一:那些系统视图 1. 系统视图是干什么呢? 从名字上看就知道,系统视图嘛?猜的不错的话,就是存放一些sqlserver系统的一些信息,很好,恭喜你,答对了.   2. 都定义在哪呢?  为了让你眼见为实,下面截图看看,从截图中你可以

Sql Server之旅——第九站 看公司这些DBA们设计的这些复合索引

原文:Sql Server之旅--第九站 看公司这些DBA们设计的这些复合索引 这一篇再说下索引的最后一个主题,索引覆盖,当然学习比较好的捷径是看看那些大师们设计的索引,看从中能提取些什么营养的东西,下面我们看 看数据库中一个核心的Orders表. 一:查看表的架构 <1> 先查看这个表的大概架构信息 1 --查看表的架构信息 2 SELECT c.column_id,c.name,t.name FROM sys.columns AS c 3 JOIN sys.types t 4 ON c.s

微软SQL Server 2000 Reporting Services介绍(四)

server|services|微软 微软SQL Server 2000 Reporting Services介绍(四) [摘要 ] 本文对Reporting Services的一些不太常见的功能进行了分析,最后根据使用情况列举了Reporting Services的一些不足的地方,估计这些不足都会在正式版中解决. [关键字] Reporting Services,.NET Framework. DrillThrough,rdl文件,rds文件 n rdl文件元素 在上一篇文章里简单的分析了rd