數(shù)據(jù)庫(kù)系統(tǒng)使用鎖是為了支持對(duì)共享資源進(jìn)行并發(fā)訪問，保障數(shù)據(jù)的完整性和一致性。

鎖設(shè)計(jì)

不同存儲(chǔ)引擎的鎖設(shè)計(jì)是不一樣的，InnoDB 存儲(chǔ)引擎會(huì)在行級(jí)對(duì)數(shù)據(jù)上鎖，不過 InnoDB 存儲(chǔ)引擎也會(huì)在數(shù)據(jù)庫(kù)內(nèi)部其他多個(gè)地方使用鎖。例如，操作緩存池中的LRU列表，刪除、添加、移動(dòng)LRU列表中的元素，為了保持一致性，必須有鎖的介入。MyISAM 存儲(chǔ)引擎中鎖是表鎖設(shè)計(jì)，在并發(fā)讀沒啥問題，但是相比行鎖并發(fā)寫的性能就差了很多。

InnoDB 存儲(chǔ)引擎中的鎖

InnoDB 存儲(chǔ)引擎實(shí)現(xiàn)了兩種標(biāo)準(zhǔn)的行級(jí)鎖：

• 共享鎖(S Lock):允許事務(wù)讀一行數(shù)據(jù)

• 排他鎖(X Lock):允許事務(wù)刪除或更新一行數(shù)據(jù)

如果一個(gè)事務(wù) T1 已經(jīng)獲取了行 r 的共享鎖，那么另外的事務(wù) T2 也可以獲得行 r 的共享鎖，稱鎖兼容，因?yàn)樽x共享，并沒有改變數(shù)據(jù)。但如果其他事務(wù) T3 想獲取行 r 的排他鎖，則必須等待事務(wù) T1 和 T2 釋放行 r 上的共享鎖，稱鎖不兼容。下表顯示了共享鎖和排他鎖的兼容性：

XS

X	不兼容	不兼容
S	不兼容	兼容

InnoDB 存儲(chǔ)引擎支持多粒度鎖定，這種鎖定允許事務(wù)在行級(jí)上的鎖和表級(jí)上的鎖同時(shí)存在，為了支持多粒度上加鎖 InnoDB 存儲(chǔ)引擎支持一種額外加鎖方式，稱之為意向鎖。若將上鎖的對(duì)象當(dāng)作有層級(jí)的樹圖來看，如果想對(duì)最細(xì)粒度上鎖就需要先對(duì)粗粒度上鎖。如下圖中，如果想對(duì)記錄 r 上 X 鎖，那么需要分別對(duì)數(shù)據(jù)庫(kù) A、表、頁(yè)上意向 IX 鎖，最后才能對(duì)記錄 r 上 X 鎖。

意向鎖是將鎖定的對(duì)象分為多個(gè)層次，意向鎖意味著事務(wù)希望在更細(xì)粒度上進(jìn)行加鎖。意向鎖的設(shè)計(jì)比較簡(jiǎn)練，其意向鎖即為表級(jí)鎖，目的主要為了在一個(gè)事務(wù)中揭示下一行將被請(qǐng)求的鎖類型。其支持兩種意向鎖：

• 意向共享鎖(IS Lock):事務(wù)想要獲得一張表中的某些行數(shù)據(jù)的共享鎖

• 意向排他鎖(IX Lock):事務(wù)想要獲得一張表中的某些行數(shù)據(jù)的排他鎖 由于 InnoDB 存儲(chǔ)引擎支持的是行級(jí)的鎖，因此意向鎖并不會(huì)阻塞除全部掃以外的任何請(qǐng)求。表級(jí)意向鎖和行級(jí)鎖的兼容性如下表：

ISIXSX

IS	兼容	兼容	兼容	不兼容
IX	兼容	兼容	不兼容	不兼容
S	兼容	不兼容	兼容	不兼容
X	不兼容	不兼容	不兼容	不兼容

向一個(gè)表添加表級(jí) X 鎖的時(shí)候(執(zhí)行 ALTER TABLE, DROP TABLE, LOCK TABLES 等操作)，如果沒有意向鎖的話，則需要遍歷所有整個(gè)表判斷是否有行鎖的存在，以免發(fā)生沖突。如果有了意向鎖，只需要判斷該意向鎖與即將添加的表級(jí)鎖是否兼容即可。因?yàn)橐庀蜴i的存在代表了，有行級(jí)鎖的存在或者即將有行級(jí)鎖的存在，因而無需遍歷整個(gè)表，即可獲取結(jié)果。

鎖狀態(tài)

在 InnoDB 1.0 版本之前，用戶可以通過?SHOW ENGINE INNODB STATUS?命令查看當(dāng)前鎖請(qǐng)求的信息。從 InnoDB 1.0 版本開始，在 INFORMATION_SCHEMA 架構(gòu)下添加了表 INNODB_TRX、INNODB_LOCKS、INNODB_LOCK_WAITS 三張表，用戶可以更簡(jiǎn)單地監(jiān)控當(dāng)前事務(wù)和鎖狀態(tài)。表結(jié)構(gòu)如下：

鎖的算法

InnoDB 存儲(chǔ)引擎由三種行鎖算法，如下：

• Record Lock：單行記錄鎖

• Gap Lock：間隙鎖，鎖定一定范圍，不包含記錄本身

• Next-Key Lock：鎖定一定范圍并且包含記錄本身

Next-Key Lock 是結(jié)合 Record Lock 和 Gap Lock 的一種鎖算法，在 Next-Key Lock 算法下，InnoDB 存儲(chǔ)引擎對(duì)于行的查詢都采用的是這種鎖定方式。例如一個(gè)索引有 10、11、13 和 20 這四個(gè)值，那么該索引可能被 Next-Key Locking 的區(qū)間為：(-∞，10]、(10，11]、(11，13]、(13，20]、(20，+∞)。當(dāng)查詢的索引是唯一鍵(單列唯一)，InnoDB 存儲(chǔ)引擎會(huì)對(duì) Next-Key Lock 進(jìn)行優(yōu)化降級(jí)為 Record Lock，僅需要鎖住本身即可。

Next-Key Lock 鎖算法解決了幻讀問題。幻讀問題是指在同一個(gè)事務(wù)下，連續(xù)執(zhí)行兩次同樣的 SQL 語(yǔ)句可能返回不同的結(jié)果，第二次的 SQL語(yǔ)句可能返回之前不存在的行。通過 Next-Key Lock 算法，即使用戶通過索引查詢一個(gè)不存在的值，其鎖定的也是一個(gè)范圍，另一個(gè)事務(wù)的操作是不會(huì)執(zhí)行的，這樣便避免了幻讀。

阻塞

鎖等待就帶來了阻塞，在 InnoDB 存儲(chǔ)引擎中參數(shù)?innodb_lock_wait_timeout?用來控制等待時(shí)間，參數(shù)?innodb_rollback_on_timeout?用來設(shè)置等待超時(shí)事務(wù)是否回滾。

死鎖

死鎖是指兩個(gè)或兩個(gè)以上的事務(wù)在執(zhí)行過程中，因資源競(jìng)爭(zhēng)而造成的互相等待的現(xiàn)象。

死鎖的四個(gè)必要條件：

• 互斥條件：一個(gè)資源每次只能被一個(gè)進(jìn)程使用。

• 占有且等待：一個(gè)進(jìn)程因請(qǐng)求資源而阻塞時(shí)，對(duì)已獲得的資源保持不放。

• 不可強(qiáng)行占有:進(jìn)程已獲得的資源，在末使用完之前，不能強(qiáng)行剝奪。

• 循環(huán)等待條件:若干進(jìn)程之間形成一種頭尾相接的循環(huán)等待資源關(guān)系。

若無外力作用事務(wù)將無法推進(jìn)，解決死鎖問題最簡(jiǎn)單的方法就是超時(shí)，即當(dāng)兩個(gè)事務(wù)死鎖，當(dāng)一個(gè)事務(wù)達(dá)到等待閾值回滾，另一個(gè)事務(wù)繼續(xù)執(zhí)行。超時(shí)機(jī)制簡(jiǎn)單，但如果超時(shí)的事務(wù)很大很重，回滾的代價(jià)會(huì)很大。除了超時(shí)機(jī)制，InnoDB 存儲(chǔ)引擎還提供了 wait-for graph(等待圖) 的方式進(jìn)行死鎖檢測(cè)。

wait-for graph? 要求數(shù)據(jù)庫(kù)保存鎖的信息鏈路和事務(wù)等待鏈路，通過它們構(gòu)造出一張圖，而這張圖中若存在回路就代表死鎖，因?yàn)橘Y源間發(fā)生了相互等待。wait-for graph 是主動(dòng)的死鎖檢測(cè)機(jī)制，在每個(gè)事務(wù)請(qǐng)求鎖并發(fā)生等待時(shí)都會(huì)判斷是否存在回路，如果存在死鎖 InnoDB 存儲(chǔ)引擎通常選擇回滾 undo 量最小的事務(wù)，從而減少性能損耗。

鎖升級(jí)

鎖升級(jí)是指粗化當(dāng)前鎖的粒度，如把 1000 個(gè)行鎖升級(jí)為一個(gè)頁(yè)鎖。InnoDB 存儲(chǔ)引擎中不存在鎖升級(jí)，這是因?yàn)?InnoDB 存儲(chǔ)引擎不是通過行記錄產(chǎn)生行鎖的，而是通過每個(gè)事務(wù)訪問的每個(gè)頁(yè)通過位圖對(duì)鎖進(jìn)行管理，因此一個(gè)事務(wù)不管是鎖住一個(gè)頁(yè)的一條記錄還是多條記錄，開銷通常是一致的。

---

公眾號(hào)文章同步github。

本文地址：github.com/lazecoding/Note/blob/main/note/articles/mysql/鎖.MD

總結(jié)

以上是生活随笔為你收集整理的firebird 行级锁问题_MySQL 锁的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。