表級(jí)鎖命令LOCK TABLE

在PG中，顯式地在表上加鎖的命令為“LOCK TABLE”，此命令的語(yǔ)法如下：

LOCK [TABLE] [ONLY] name [,...][IN lockmode MODE] [NOWAIT]

語(yǔ)法中各項(xiàng)參數(shù)說(shuō)明如下：

• name：表名
• lockmode：表級(jí)鎖模式，即SHARE、EXCLUSIVE、ACCESS SHARE、ACCESS EXCLUSIVE、ROW SHARE、ROW EXCLUSIVE、SHARE UPDATE EXCLUSIVE、SHARE ROW EXCLUSIVE
• NOWAIT：如果沒(méi)有NOWAIT這個(gè)關(guān)鍵字，當(dāng)無(wú)法獲得鎖時(shí)會(huì)一直等待，而如果加了NOWAIT關(guān)鍵字，在無(wú)法立即獲取該鎖時(shí)，此命令會(huì)立即退出并且報(bào)錯(cuò)

在PG中，事務(wù)自己的鎖是從不沖突的，因此一個(gè)事務(wù)可以在持有SHARE模式的鎖時(shí)再請(qǐng)求ROW EXCLUSIVE鎖，而不會(huì)出現(xiàn)自己的鎖阻塞自己的情況。

當(dāng)事務(wù)要更新表中的數(shù)據(jù)時(shí)，應(yīng)該申請(qǐng)ROW EXCLUSIVE鎖，而不應(yīng)該申請(qǐng)SHARE鎖，因?yàn)樵诟聰?shù)據(jù)時(shí)，事務(wù)還是會(huì)對(duì)表加ROW EXCLUSIVE鎖，想象一下，在兩個(gè)并發(fā)的事務(wù)都請(qǐng)求SHARE鎖后，開(kāi)始更新數(shù)據(jù)前要對(duì)表加ROW EXCLUSIVE鎖，但由于各自先前已加了SHARE鎖，所以都要等待對(duì)方釋放SHARE鎖，因而出現(xiàn)死鎖。從這個(gè)示例可以看出，如果涉及多種鎖模式，那么事務(wù)應(yīng)該總是最先請(qǐng)求最嚴(yán)格的鎖模式，否則就容易出現(xiàn)死鎖。

行級(jí)鎖命令

顯式的行級(jí)鎖命令是由SELECT命令后加如下子句來(lái)構(gòu)成的：

SELECT ... FOR {UPDATE | SHARE} [OF table_name [,...]] [NOWAIT] [...]

• NOWAIT關(guān)鍵字加上，如果無(wú)法獲得鎖則直接報(bào)錯(cuò)，而不會(huì)一直等待。
• OF table_name明確指定表名字，那么只有被指定的表會(huì)被鎖定，其他在SELECT中使用的表則不會(huì)
• 不帶OF table_name的FOR UPDATE或者FOR SHARE子句將鎖定該命令中使用的所有表
• 如果FOR UPDATE或者FOR SHARE應(yīng)用于一個(gè)視圖或者子查詢，那么它將同樣鎖定該視圖或者子查詢中使用到的所有表
• 主查詢中引用了WITH查詢時(shí)，WITH查詢中的表并不會(huì)被鎖定
• 如果想要鎖定WITH查詢內(nèi)的表行，需要在WITH查詢內(nèi)指定FOR UPDATE或者FOR SHARE關(guān)鍵字

鎖的查看

我們經(jīng)常需要查看一個(gè)事務(wù)產(chǎn)生了哪些鎖，哪個(gè)事務(wù)被哪個(gè)事務(wù)阻塞了，若執(zhí)行一條SQL語(yǔ)句時(shí)阻塞住了，需要查詢?yōu)槭裁醋枞钦l(shuí)阻塞住的，這些信息可以通過(guò)查詢系統(tǒng)視圖“pg_locks”來(lái)得到。pg_locks視圖中各列的描述如下：

上述中，描述事務(wù)id的字段有三個(gè)：

• virtualxid
• transactionid
• virtualtransaction

1. transactionid代表事務(wù)id，簡(jiǎn)寫(xiě)為“xid”
2. virtualxid代表虛擬事務(wù)id，簡(jiǎn)寫(xiě)為“vxid”
3. 每產(chǎn)生一個(gè)事務(wù)id，都會(huì)在pg_clog下的commit log文件中占用2bit
4. 最早pg中本沒(méi)有虛擬事務(wù)id，但是后來(lái)發(fā)現(xiàn)，有一些事務(wù)根本沒(méi)有產(chǎn)生任何實(shí)質(zhì)的變更，如一個(gè)只讀事務(wù)或一個(gè)空事務(wù)，若在這種情況下也分配一個(gè)事務(wù)id會(huì)造成浪費(fèi)，于是提出了虛擬事務(wù)id的概念
5. 對(duì)于這類(lèi)只讀事務(wù)，值分配一個(gè)虛擬事務(wù)id，而不是實(shí)際分配一個(gè)真實(shí)的事務(wù)id，這樣就不需要在commit log中占用2bit的空間了

pg_locks這張視圖的字段分為以下兩部分：

• virtualtransaction之前的字段（不包括virtualtransaction字段），我們稱其為“第一部分”，用于描述鎖定對(duì)象（Locked Object）信息
• virtualtransaction之后的字段（包括virtualtransaction字段），我們稱其為“第二部分”，用于描述持有鎖或等待鎖的session信息

了解上述概念后，可以容易理解virtualxid和virtualtransaction兩個(gè)字段的意思：

• virtualxid在第一部分字段中，表示鎖對(duì)象是一個(gè)virtualxid
• virtualtransaction表示持有鎖或等待鎖session的虛擬事務(wù)id

表鎖實(shí)操

1.先開(kāi)一個(gè)psql窗口，命令如下：

第一個(gè)窗口，查詢PID，并鎖定一張表。

2.第二個(gè)窗口中查看數(shù)據(jù)庫(kù)中的鎖的情況：

sql命令：

select locktype,relation::regclass as rel,virtualxid as vxid,transactionid as xid,virtualtransaction as vxid2,pid,mode,granted from pg_locks where pid = 12264;

通過(guò)上述圖片可以看出：

• 第一行顯示的是事務(wù)在自己的“virtualxid”上加的ExclusiveLock鎖，這是必定會(huì)加上的
• 第二行才是我們實(shí)際在表上加的鎖“AccessExclusiveLock”

3.新增一個(gè)窗口，顯示地對(duì)表加鎖：

執(zhí)行sql語(yǔ)句發(fā)現(xiàn)，該窗口的鎖表語(yǔ)句會(huì)被阻塞住

4.查看兩個(gè)進(jìn)程的鎖情況：

• 發(fā)現(xiàn)兩個(gè)進(jìn)程都對(duì)表加了鎖
• 進(jìn)程12264中的granted字段為t，說(shuō)明它獲得了這把鎖
• 進(jìn)程21052中的granted字段為f，說(shuō)明該進(jìn)程沒(méi)有獲得這把鎖，從而被阻塞

行鎖實(shí)操

1.第一個(gè)窗口執(zhí)行如下操作（在加表鎖的基礎(chǔ)上加行鎖）：

2.第二個(gè)窗口中查看數(shù)據(jù)庫(kù)中的鎖的情況：

行鎖不僅會(huì)在表上加意向鎖，也會(huì)在相應(yīng)的主鍵上加意向鎖。其中“jxx_test_pkey”就是表的主鍵。

3.另一個(gè)窗口加行鎖：

該窗口阻塞

4.第二個(gè)窗口中查看數(shù)據(jù)庫(kù)中的鎖的情況：

xid為739的鎖被進(jìn)程12264持有了，所以21052的進(jìn)程獲取鎖標(biāo)識(shí)為False

5.如何查看具體是哪一行數(shù)據(jù)被阻塞

-- 其中0和1分別代表pg_locks中的page和tuple字段
select * from jxx_test where ctid = '(0,1)'

pg_locks并不能顯示出每個(gè)行鎖的信息，因?yàn)樾墟i信息并不會(huì)被記錄到共享內(nèi)存中。如果記錄到內(nèi)存，意味著對(duì)表做全表更新時(shí)，表有多少行就需要在內(nèi)存中記錄多少條行鎖信息，那么內(nèi)存會(huì)吃不消，所以postgreSQL設(shè)計(jì)成不在內(nèi)存中記錄行鎖信息。

思考：如何獲取進(jìn)程是在哪一行上被阻塞的？

總結(jié)

到此這篇關(guān)于PostgreSQL如何查看事務(wù)所占有的鎖的文章就介紹到這了,更多相關(guān)PostgreSQL查看事務(wù)所占有鎖內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論