前言

在座的朋友們，你們的時(shí)間夠用嗎？想要成為一個(gè)成功的人嗎？如果你們都有這樣的疑惑，那就保持一刻謙虛的心態(tài)，跟著羅老師學(xué)習(xí)時(shí)間管理吧！

畢竟時(shí)間管理大師是一個(gè)用戶訪問(wèn)多個(gè)資源，今天咱們來(lái)講講當(dāng)多個(gè)用戶并發(fā)訪問(wèn)同一個(gè)資源時(shí)的情況

在數(shù)據(jù)庫(kù)中，如果多個(gè)事務(wù)同時(shí)對(duì)一個(gè)數(shù)據(jù)進(jìn)行操作，并發(fā)的操作若不加控制，可能會(huì)讀取和存儲(chǔ)不正確的數(shù)據(jù)，破壞數(shù)據(jù)庫(kù)的一致性、臟讀、不可重復(fù)讀、幻讀等、甚至可能產(chǎn)生死鎖。

為了解決這個(gè)問(wèn)題，加鎖是一個(gè)非常重要的技術(shù)，對(duì)實(shí)現(xiàn)數(shù)據(jù)庫(kù)并發(fā)控制是一個(gè)好的方案。

簡(jiǎn)單說(shuō)，當(dāng)一個(gè)執(zhí)行 sql 語(yǔ)句的事務(wù)想要操作表記錄之前，先向數(shù)據(jù)庫(kù)發(fā)出請(qǐng)求，對(duì)你訪問(wèn)的記錄加鎖，在這個(gè)事務(wù)釋放這個(gè)鎖之前，其他事務(wù)不能對(duì)這些數(shù)據(jù)進(jìn)行更新操作。

本文將基于 MySQL，介紹數(shù)據(jù)庫(kù)鎖機(jī)制，相信大家耐心看了之后肯定有收獲，碼字不易，別忘了「在看」，「轉(zhuǎn)發(fā)」哦。

• 鎖的類型

• MyISAM 鎖機(jī)制
  

• InnoDB 鎖機(jī)制

01 鎖的類型

從對(duì)數(shù)據(jù)的操作粒度來(lái)劃分，MySQL 大致可歸納為 3 種鎖。

表級(jí)鎖

表級(jí)別的鎖定是 MySQL 各存儲(chǔ)引擎中最大顆粒度的鎖定機(jī)制。該鎖定機(jī)制最大的特點(diǎn)是實(shí)現(xiàn)邏輯非常簡(jiǎn)單，帶來(lái)的系統(tǒng)負(fù)面影響最小。

所以獲取鎖和釋放鎖的速度很快。由于表級(jí)鎖一次會(huì)將整個(gè)表鎖定，所以可以很好的避免困擾我們的死鎖問(wèn)題。

當(dāng)然，鎖定顆粒度大所帶來(lái)最大的負(fù)面影響就是出現(xiàn)鎖定資源爭(zhēng)用的概率也會(huì)最高，致使并發(fā)大度大打折扣。

行級(jí)鎖

行級(jí)鎖定最大的特點(diǎn)就是鎖定對(duì)象的顆粒度很小，也是目前各大數(shù)據(jù)庫(kù)管理軟件所實(shí)現(xiàn)的鎖定顆粒度最小的。

由于鎖定顆粒度很小，所以發(fā)生鎖定資源爭(zhēng)用的概率也最小，能夠給予應(yīng)用程序盡可能大的并發(fā)處理能力而提高一些需要高并發(fā)應(yīng)用系統(tǒng)的整體性能。

雖然能夠在并發(fā)處理能力上面有較大的優(yōu)勢(shì)，但是行級(jí)鎖定也因此帶來(lái)了不少弊端。由于鎖定資源的顆粒度很小，所以每次獲取鎖和釋放鎖需要做的事情也更多，帶來(lái)的消耗自然也就更大了。此外，行級(jí)鎖定也最容易發(fā)生死鎖。

頁(yè)級(jí)鎖

頁(yè)面鎖會(huì)去鎖定一頁(yè)的數(shù)據(jù)，我們知道 MySQL 的索引本身是由 B+ 樹(shù)實(shí)現(xiàn)的。

每個(gè)葉子節(jié)點(diǎn)的單位頁(yè)，葉子節(jié)點(diǎn)上面存放了多個(gè)記錄行，數(shù)據(jù)存儲(chǔ)是按照一頁(yè)一頁(yè)來(lái)的，每次鎖定一頁(yè)的數(shù)據(jù)，其實(shí)就是相鄰的數(shù)據(jù)，開(kāi)銷和加鎖時(shí)間界于表鎖和行鎖之間。

頁(yè)級(jí)鎖也會(huì)出現(xiàn)死鎖；鎖定粒度界于表鎖和行鎖之間，并發(fā)度一般。

02 MyISAM鎖機(jī)制

MyISAM引擎只提供表鎖。

在執(zhí)行查詢語(yǔ)句（ SELECT ）前，會(huì)自動(dòng)給涉及的表加讀鎖，此時(shí)允許其他用戶對(duì)同一表的讀操作。但會(huì)阻塞對(duì)同一個(gè)表的寫(xiě)操作。

在執(zhí)行更新操作（ UPDATE、DELETE、INSERT 等）前，會(huì)自動(dòng)給涉及的表加寫(xiě)鎖，此時(shí)會(huì)阻塞其他用戶對(duì)同一個(gè)表的讀操作和寫(xiě)操作。

03 InnoDB鎖機(jī)制

InnoDB 支持表鎖、行鎖，實(shí)際上InnoDB 是通過(guò)給索引項(xiàng)加鎖，來(lái)實(shí)現(xiàn)行鎖的。

只有查詢數(shù)據(jù)時(shí)，檢索條件走索引才可以使用行級(jí)鎖，否則 InnoDB 將使用表鎖。

在實(shí)際開(kāi)發(fā)中，要特別注意 InnoDB 這一特性，不然，可能造成大量的鎖沖突，從而影響并發(fā)?。?！

InnoDB使用索引的條件

（1）在不通過(guò)索引條件查詢的時(shí)候，InnoDB 確實(shí)使用的是表鎖，而不是行鎖。

（2）行鎖是針對(duì)索引加鎖，不是針對(duì)記錄加的鎖。即使訪問(wèn)的是不同行，但如果它們索引相同，還是會(huì)出現(xiàn)鎖沖突。

（3）當(dāng)表中含有多個(gè)索引的時(shí)候，不同的事務(wù)可以使用不同的索引鎖定不同的行。

（4）即使在條件中使用了索引，但是否使用索引來(lái)檢索數(shù)據(jù)是由 MySQL 通過(guò)判斷不同執(zhí)行計(jì)劃的代價(jià)決定的。如果 MySQL 認(rèn)為全表掃描效率更高，比如很小的表，也不會(huì)使用索引，此時(shí) InnoDB 將使用表鎖，而不是行鎖。因此，在分析鎖沖突的時(shí)候，不要忘記檢查 SQL 的執(zhí)行計(jì)劃，以確定是否真正使用了索引。

在默認(rèn)的可重復(fù)讀隔離級(jí)別下：

執(zhí)行查詢語(yǔ)句（ SELECT ）前，由于 MVCC（多版本控制）的方式，什么鎖都不會(huì)加。

在執(zhí)行更新操作（ UPDATE、DELETE、INSERT 等）前，會(huì)自動(dòng)給涉及的行加寫(xiě)鎖，此時(shí)會(huì)阻塞其他用戶的寫(xiě)操作，但是通過(guò) MVCC（多版本控制）的方式允許讀操作。

04 總結(jié)

通過(guò)這篇文章，基于MySQL，為大家介紹了數(shù)據(jù)庫(kù)的鎖機(jī)制。針對(duì)不同情況，什么時(shí)候使用鎖，鎖到底生不生效是大家需要關(guān)注的問(wèn)題。

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒(méi)關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：
長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝