前言

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

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

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

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

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

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

• 鎖的類型

• MyISAM 鎖機(jī)制
  

• InnoDB 鎖機(jī)制

01 鎖的類型

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

表級鎖

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

所以獲取鎖和釋放鎖的速度很快。由于表級鎖一次會將整個表鎖定，所以可以很好的避免困擾我們的死鎖問題。

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

行級鎖

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

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

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

頁級鎖

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

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

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

02 MyISAM鎖機(jī)制

MyISAM引擎只提供表鎖。

在執(zhí)行查詢語句（ SELECT ）前，會自動給涉及的表加讀鎖，此時允許其他用戶對同一表的讀操作。但會阻塞對同一個表的寫操作。

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

03 InnoDB鎖機(jī)制

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

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

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

InnoDB使用索引的條件

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

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

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

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

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

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

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

04 總結(jié)

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

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