zoukankan      html  css  js  c++  java
  • 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利器,,,自己多试验试

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

  • 相关阅读:
    使用postman解决接口之间的接口依赖
    loadrunner11安装
    记录一次搭建jmeter分布式压测环境时creatermikeystore.bat不是内部命令
    jmeter分布式压测环境搭建(jmeter版本5.1.1,jdk版本jdk1.8.0_221)
    jmeter基于windows分布式压测环境搭建
    Chrome浏览器一直请求clients1.google.com:443
    Nginx 配置支持C++
    Ubuntu Sublime Text 设置等宽字体
    取任意四边形最长边
    调用Lua脚本print(xxx)报attempt to call a nil value (global 'print')错误
  • 原文地址:https://www.cnblogs.com/huangxincheng/p/4291446.html
Copyright © 2011-2022 走看看