Sql Server深入的探討鎖機制
上一篇我只是做了一個堆表讓大家初步的認識到鎖的痙攣狀態,但是在現實世界上並沒有這麼簡單的事情,起碼我的表不會沒有索引對吧,,,還
有就是我的表一定會有很多的連線過來,10:1的讀寫,很多碼農可能都會遇到類似神乎其神的死鎖,卡住,讀不出來,插不進入等等神仙的事情導致性
能低下,這篇我們一起來探討下。
一: 當select遇到效能低下的update會怎麼樣?
1. 還是使用原始的person表,插入6條資料,由於是4000位元組,所以兩條資料就是一個資料頁,如下圖:
1 DROP TABLE dbo.Person2 CREATE TABLE Person(ID INT IDENTITY,NAME CHAR(4000) DEFAULT 'aaaaa')3 --插入6條資料,剛好3個資料頁4 INSERT INTO dbo.Person DEFAULT VALUES5 go 6
2. 為了模擬效能低下的Update操作,我們開個顯式事務來更新ID=4的記錄,並且用profile看一下,如下圖:
1 BEGIN TRAN2 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 l6 LEFT JOIN sys.partitions AS p7 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列上建一個index2 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 TRANUPDATE 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利器,,,自己多試驗試
驗就好,畢竟我也是這樣,晚上再發布最後一篇,明天晚上回家。。。這樣就可以安心順利的過大年了。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/2768/viewspace-2811496/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- SQL Server之旅(14):深入的探討鎖機制SQLServer
- Sql Server之旅——第十四站 深入的探討鎖機制SQLServer
- 深入理解 SQL Server 2008 的鎖機制SQLServer
- 專訪:深入探討SQL Server主資料服務ATSQLServer
- 深入探討微服務架構中的同步通訊機制微服務架構
- 跟著辛星深入探討一下PHP的反射機制PHP反射
- 訂單系統中併發問題和鎖機制的探討
- 深入探討 UndefinedUndefined
- IsPostBack深入探討
- SQL鎖機制SQL
- [轉帖]SQL Server 鎖機制 悲觀鎖 樂觀鎖 實測解析SQLServer
- Oracle Stream 深入探討Oracle
- MS SQL鎖機制SQL
- 深入探討、理解Java的CLASSPATHJava
- 深入探討程式間通訊的重要性:理解不同的通訊機制(下)
- 深入探討程式間通訊的重要性:理解不同的通訊機制(上)
- ORACLE鎖機制深入理解Oracle
- MS SQL Server資料庫事務鎖機制分析(轉)SQLServer資料庫
- 深入探討單例模式單例模式
- 探討代理模式與Java反射機制的應用模式Java反射
- Java執行緒的深入探討Java執行緒
- 【轉】關於oracle中Move機制的一點探討Oracle
- 基於DirectDraw的Gamma calibrator機制之探討 (轉)GAM
- 深入探討ROP 載荷分析
- 深入探討JavaScript函式物件JavaScript函式物件
- Java HashMap工作原理深入探討JavaHashMap
- 深入探討 Room 2.4.0 的最新進展OOM
- Java執行緒的深入探討 (轉)Java執行緒
- SQL Server 鎖SQLServer
- SQL Server 的死鎖SQLServer
- 深入探討前端元件化開發前端元件化
- 深入探討 Java 類載入器Java
- SQL優化器探討(zt)SQL優化
- 探討電子遊戲應如何設定簡單的成就機制遊戲
- SQL Server重做日誌管理機制SQLServer
- IsPostBack深入探討(轉轉轉轉轉)
- CSS中Position、Float屬性深入探討CSS
- Java原始碼分析:深入探討Iterator模式Java原始碼模式