?一：背景
1. 講故事
相信絕大部分用 SQLSERVER 作為底層存儲(chǔ)的程序員都知道 nolock? 關(guān)鍵詞，即使當(dāng)時(shí)不知道也會(huì)在踩過(guò)若干阻塞坑?之后果斷的加上 nolock，但這玩意有什么注意事項(xiàng)呢？這就需要了解它的底層原理了。
二：nolock 的原理
1. sql 阻塞還原
為了方便講述，先創(chuàng)建一個(gè) post 表，插個(gè) 6 條記錄，參考代碼如下：
CREATE TABLE post(id INT IDENTITY,content char(4000))
GO
INSERT INTO dbo.post VALUES('aaa')
INSERT INTO dbo.post VALUES('bbb')
INSERT INTO dbo.post VALUES('ccc');
INSERT INTO dbo.post VALUES('ddd');
INSERT INTO dbo.post VALUES('eee');
INSERT INTO dbo.post VALUES('fff');
這里為了簡(jiǎn)單我沒(méi)有創(chuàng)建索引，所以會(huì)出現(xiàn) Table Scan? 的情況，畢竟生產(chǎn)環(huán)境下的sql也避免不了 Table Scan? 和 Clustered Index Scan? 的存在，接下來(lái)還原下阻塞場(chǎng)景，開啟兩個(gè) session 會(huì)話, session1 為正在運(yùn)行的 update? 事務(wù), session2 為一個(gè)簡(jiǎn)單的 select 操作，這種場(chǎng)景下會(huì)導(dǎo)致 session2 阻塞，參考代碼如下：
- session1
BEGIN TRAN
UPDATE post SET content='xxxxx' WHERE id=3
- session2
SELECT * FROM post WHERE id=4
從圖中可以看到，這個(gè) select 已經(jīng)阻塞 9 分鐘了，那為什么會(huì)被阻塞呢？可以觀察 SQLSERVER 內(nèi)部的統(tǒng)計(jì)信息，比如鎖相關(guān)的動(dòng)態(tài)視圖 sys.dm_tran_locks ，參考代碼如下：
SELECT t.request_session_id,
CASE
WHEN t.resource_type = 'OBJECT' THEN
OBJECT_NAME(t.resource_associated_entity_id)
WHEN t.resource_associated_entity_id = 0 THEN
'/'
ELSE
OBJECT_NAME(p.object_id)
END AS resource_name,
index_id,
t.resource_type,
t.resource_description AS description,
t.request_mode AS mode,
t.request_status AS status
FROM sys.dm_tran_locks AS t
LEFT JOIN sys.partitions AS p
ON p.hobt_id = t.resource_associated_entity_id
WHERE t.resource_database_id = DB_ID()
從圖中看，session55 準(zhǔn)備在 1:489:0? 這個(gè)槽位指向的記錄上附加 S 鎖時(shí)被阻塞，因?yàn)?nbsp;1:489:0 已經(jīng)被附加了 X 鎖，很顯然這個(gè) X 鎖是 update 給的。
上面給出的是一個(gè) 靜態(tài)視圖，為了方便顯示動(dòng)態(tài)視圖，這里把 sql profile 開起來(lái)觀察兩個(gè) session 給鎖的過(guò)程，事件選擇上如下所示：
將 sqlprofile 開啟后，重新運(yùn)行下剛才的兩個(gè)會(huì)話，觀察 profile 的走勢(shì)，截圖如下：
圖中的注釋已經(jīng)說(shuō)的非常清楚了，和 sys.dm_tran_locks? 顯示的一致，有了這些基礎(chǔ)后接下來(lái)觀察下如果加上 with (nolock) 會(huì)怎么樣？
SELECT * FROM post(NOLOCK) WHERE id=4
你會(huì)發(fā)現(xiàn)結(jié)果是可以出來(lái)的，那為什么可以出來(lái)呢？繼續(xù)觀察下 profile 即可。
從 session 55 的 lock 輸出來(lái)看，with(nolock)? 會(huì)對(duì) post 表附加 Sch-S? 架構(gòu)穩(wěn)定鎖，以及分區(qū)中的 堆或BTree 附加S鎖， 而不再對(duì) PAGE 附加任何鎖了，所以就不存在阻塞的情況，但肯定會(huì)引起臟讀。
到這里基本上就是 nolock 的底層玩法了吧，不過(guò)也有一個(gè)注意點(diǎn)，nolock 真的不會(huì)引發(fā)阻塞嗎? 接下來(lái)我們好好聊一聊。
3. nolock 真的無(wú)視阻塞嗎
從 sqlprofile 觀察鎖的走勢(shì)圖來(lái)看，nolock 只是在上限為 page 頁(yè)級(jí)別上做到無(wú)視，但在 page? 之上就無(wú)法做到了，比如你看到的 Sch-S?,可能有些朋友要問(wèn)了，為什么要加上 Sch-S 鎖呢？其實(shí)很簡(jiǎn)單，在 query 的過(guò)程中一定要保持架構(gòu)穩(wěn)定嘛，不能在 query 的過(guò)程中，post 表突然被刪了，這樣大家多尷尬。
接下來(lái)也可以做個(gè)簡(jiǎn)單的測(cè)試。
----- session 1
BEGIN TRAN
TRUNCATE TABLE post;
----- session 2
SELECT * FROM post(NOLOCK) WHERE id=4
可以發(fā)現(xiàn) nolock 查詢也被阻塞了，原因就在于拿不到 post 表的 Sch-S? 鎖，因?yàn)?nbsp;TRUNCATE? 已經(jīng)給 post 附加了 Sch-M? 架構(gòu)修改鎖，那有沒(méi)有數(shù)據(jù)支撐呢？繼續(xù)用動(dòng)態(tài)視圖 sys.dm_tran_locks 觀察便可。
三：總結(jié)
綜上所述，nolock 也僅在 page 級(jí)別上暢通無(wú)阻，在某些情況下也會(huì)有阻塞情況的發(fā)生，由于無(wú)鎖自然就會(huì)讀到別的會(huì)話已修改但還未提交的記錄，sqlserver 作為一個(gè)數(shù)據(jù)庫(kù)應(yīng)用程序，里面包含了大量的運(yùn)行時(shí)統(tǒng)計(jì)信息，這些統(tǒng)計(jì)信息可以用 系統(tǒng)視圖? 和 動(dòng)態(tài)視圖 獲取，完全可以基于它們做一個(gè)完善的 APM 監(jiān)控。
