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

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

  终于这个系列快结束了,马上又要过年了,没什么心情写博客。。。作为一个开发人员,锁机制也是我们程序员必须掌握的东西,很久之前

在学习锁的时候,都是教科书上怎么说,然后我怎么背,缺少一个工具让我们眼见为实。。。如果这样的话,学习一个东西就很容易忘记。。。

因为这些都是你背诵过来的。。。这篇的话我就来分享一个工具来帮助我们学习锁。

 

一:到底都有哪些锁

  学习锁之前,必须要知道锁大概有几种???通常情况下作为码农我们只需知道如下几个锁即可。。。

1.S(Share)锁

  为了方便理解,我们可以直接这么认为,当在select的时候在表,数据页,记录上加上共享锁。

2.X(Exclusive) 锁

  我们在delete数据的时候会在记录上附加X锁,我们知道X锁并不与其他的锁兼容。如果其他的锁与其遭遇,就会处于等待,后续我们再说。

3.U(Update)锁

  顾名思义,我们在Update的时候,在寻找记录的过程中,会逐一的给记录附加U锁,如果找到了目标记录的话,则会将U锁转化为X锁。。。

4.I (Intent)锁

  这个就是所谓的意向锁,一般都是给表和数据页附加的锁,好处就是防止被其他连接修改表结构。

 

二:天下无敌的SqlServer Profile

  这个工具我想大家都明白,它的监视能力真的是无所不能。。。锁的痉挛状态也全在它的掌握之中。

1. 首先我做一个Person表,Name字段设定4000字节,这样一个数据页可以容纳2条数据,如下图:

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

 

2. 下面我们看看数据在数据页的分布情况。

 

3. 然后我们开启Profile,在“事件选择”的Events中选择”Lock:Acquired“和”Lock:Released“ ,然后运行,如下图:

 

三:使用测试数据

1. 首先我执行一个简单的 SELECT * FROM dbo.Person,看看表/数据页/记录的加锁情况。

从图中可以看到,select执行的大概步骤如下:

第一步:给表(Object)加上IS(意向共享锁)。

第二步:先给1:78号数据页加IS锁,扫描78号数据页,然后释放IS锁。

第三步:同样的道理扫描之后的数据页。

第四步:最后释放表的IS锁,结束整个锁流程。

看完上面的一系列的Lock:Acquired 和 Lock:Released的话,你有没有发现一个问题,不是说好给记录(RID)加上S锁么???这里没加,

是因为引擎进入78号数据页的时候,未发现它存在IU锁或者IX锁。。。所以。。。这个属于锁的组合,后续会说。

 

2. 接下来用UPDATE dbo.Person SET NAME='bbbbb' WHERE ID=3来看看update的整个过程,乍一看,Profile捕获到的记录还是比较多

  的,下面具体看图:

 第一步: 给表(Object)加上IX锁,

 第二步: 给数据页(1:78)数据页分配IU锁。然后开始逐一扫描78号数据页的RID记录,进入前就Acquired,退出后就Released,当扫

      描完78号数据页的所有RID后,再释放78号数据页的IU锁,进入下一个数据页。。。

 第三步: 我们发现ID=3是在89号数据页上,当引擎扫到该RID之后,我们观察到89号的数据页由IU锁变成了IX锁,并且把1:89:0(slot

      为0的记录)由U锁变成X锁,变成X锁后,就排斥了其他所有的锁,这时候就可以进行Update操作了。

 第四步: 后面就继续90号数据页,步骤类似,第二步和第三步。

不知道细心的你有没有发现,在Released Object之前我们才释放1:89:0的X锁,然后释放89号数据页的IX锁,这说明什么???说明这个

Update是贯穿于这个事务的,不像Select操作中,扫完一个数据页就释放一个数据页。

 

3. 最后再看一个DELETE FROM dbo.Person WHERE ID=3 的操作。

  大概扫了一下上面的图,或许你感觉和Update操作大差不差,会扫描数据页中的每个记录并加上U锁。当在1:89:0槽位中找到了目

标记录后,然后将U锁转化为X锁,具体可以参考Update。

 

好了,最最单纯的DML操作都展示给你看了...我们知道生产环境没有这么简单,但是你有此宝贝,再多动动脑子就可天下无敌了。。。

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

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

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

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

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

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

Sql Server之旅——第十一站 简单说说sqlserver的执行计划

我们知道sql在底层的执行给我们上层人员开了一个窗口,那就是执行计划,有了执行计划之后,我们就清楚了那些烂sql是怎么执行的,这样 就可以方便的找到sql的缺陷和优化点. 一:执行计划生成过程 说到执行计划,首先要知道的是执行计划大概生成的过程,这样就可以做到就心中有数了,下面我画下简图: 1. 分析过程 这三个比较容易理解,首先我们要保证sql的语法不能错误,select和join的表是必须存在的,以及你是有执行这个sql的权限,对不对... 这样我们就走完了执行计划生命周期的第一个流程. 2

Sql Server之旅——第七站 为什么都说状态少的字段不能建索引

我们在学sqlserver的时候,大多教科书和前辈们都说状态少的字段不要建索引,由此带来的开销还不如不建索引,但是这句话有多少人真的知道, 或者说有多少人真的对此有比较深刻的理解,而不是听别人道听途说...这样记得快,忘记的也不慢...这篇我来分析一下这句话到底有几个意思.   一:现象 首先我们还是用测试数据来发现问题,我先建立一个Person,有5个字段,建表sql如下: DROP TABLE dbo.Person CREATE TABLE Person(ID INT PRIMARY KEY

Sql Server之旅——第六站 使用winHex利器加深理解数据页

        这篇我来介绍一个winhex利器,这个工具网上有介绍,用途大着呢,可以用来玩数据修复,恢复删除文件等等....它能够将一个file解析成 hex形式,这样你就可以对hex进行修改,然后你就可以看到修复后的结果,为什么要在sqlserver系列中说这个呢???很简单呀,sqlserver的DB本 质上也是一个mdf文件,对吧,既然是文件,我就可以利用winhex对它进行随意的修改,然后你也知道sqlserver的数据都是以数据页的形式封装的, 那我就可以修改它的数据页,对不对,这样

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之旅——第八站 复合索引和include索引到底有多大区别?

周末终于搬进出租房了,装了宽带....才发现没网的日子...那是一个怎样的与世隔绝呀...再也受不了那样的日子了....好了,既然网 安上去了,还得继续我的这个系列. 索引和锁,这两个主题对我们开发工程师来说,非常的重要...只有理解了这两个主题,我们才能写出高质量的sql语句,在之前的博客中,我所说的 索引都是单列索引...当然数据库不可能只认单列索引,还有我这篇的复合索引,说到复合索引,可能熟悉的人又会说到include索引,那这两个索引到底 有什么区别呢,当然我也是菜鸟一枚...所以下面的

Sql Server之旅——第三站 解惑那些背了多年聚集索引的人

说到聚集索引,我想每个码农都明白,但是也有很多像我这样的猥程序员,只能用死记硬背来解决这个问题,什么表中只能建一个聚集索引, 然后又扯到了目录查找来帮助读者记忆....问题就在这里,我们不是学文科,,,不需要去死记硬背,,,我们需要的就是能看到在眼里面的 真实东西.....我们都喜欢聚集索引,因为它能够把无序的堆表记录变成有序,还玩起了B树...这样就把复杂度从N降低到了LogMN... 这样的话逻辑读,物理读就下来了.   一:现象 1:无索引的情况 还是老规矩,看个例子感受下,首先我有一个P

Sql Server之旅——第五站 确实不得不说的DBCC命令(文后附年会福利)

一:DBCC 1:什么是DBCC 我不是教学老师,我也说不到没有任何无懈可击的定义,全名:Database Console Commands.顾名思义"数据库控制台命令",说到"控制台", 我第一反应就是chrome的开发者工具,不知道你的第一反应会是怎样?开发者工具中,只要javascript能认的语法,你都可以在控制台键入...同 样的道理sqlserver能认的也是一样.   2:DBCC到底有多少个命令  你应该知道,凡是控制台,大多都会提供一个help命令