一天吃透MySQL鎖面試八股文

本文已經收錄到Github倉庫，該倉庫包含計算機基礎、Java基礎、多執行緒、JVM、資料庫、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服務、設計模式、架構、校招社招分享等核心知識點，歡迎star~

Github地址：https://github.com/Tyson0314/Java-learning

為什么需要加鎖

如果有多個并發請求存取資料，在資料就可能會產生多個事務同時操作同一行資料，如果并發操作不加控制，不加鎖的話，就可能寫入了不正確的資料，或者導致讀取了不正確的資料，破壞了資料的一致性，因此需要考慮加鎖，

表級鎖和行級鎖有什么區別？

MyISAM 僅僅支持表級鎖，一鎖就鎖整張表，這在并發寫的情況下性非常差，

InnoDB 不光支持表級鎖，還支持行級鎖，默認為行級鎖，行級鎖的粒度更小，僅對相關的記錄上鎖即可（對一行或者多行記錄加鎖），所以對于并發寫入操作來說， InnoDB 的性能更高，

表級鎖和行級鎖對比 ：

• 表級鎖： MySQL 中鎖定粒度最大的一種鎖，是針對非索引欄位加的鎖，對當前操作的整張表加鎖，實作簡單，資源消耗也比較少，加鎖快，不會出現死鎖，其鎖定粒度最大，觸發鎖沖突的概率最高，并發度最低，MyISAM 和 InnoDB 引擎都支持表級鎖，
• 行級鎖： MySQL 中鎖定粒度最小的一種鎖，是針對索引欄位加的鎖，只針對當前操作的記錄進行加鎖， 行級鎖能大大減少資料庫操作的沖突，其加鎖粒度最小，并發度高，但加鎖的開銷也最大，加鎖慢，會出現死鎖，

共享鎖和排他鎖有什么區別？

不論是表級鎖還是行級鎖，都存在共享鎖（Share Lock，S 鎖）和排他鎖（Exclusive Lock，X 鎖）這兩類：

• 共享鎖（S 鎖） ：又稱讀鎖，事務在讀取記錄的時候獲取共享鎖，允許多個事務同時獲取（鎖兼容），
• 排他鎖（X 鎖） ：又稱寫鎖/獨占鎖，事務在修改記錄的時候獲取排他鎖，不允許多個事務同時獲取，如果一個記錄已經被加了排他鎖，那其他事務不能再對這條事務加任何型別的鎖（鎖不兼容），

排他鎖與任何的鎖都不兼容，共享鎖僅和共享鎖兼容，

由于 MVCC 的存在，對于一般的 SELECT 陳述句，InnoDB 不會加任何鎖，不過， 你可以通過以下陳述句顯式加共享鎖或排他鎖，

# 共享鎖
SELECT ... LOCK IN SHARE MODE;
# 排他鎖
SELECT ... FOR UPDATE;

意向鎖有什么作用？

如果需要用到表鎖的話，如何判斷表中的記錄沒有行鎖呢？一行一行遍歷肯定是不行，性能太差，我們需要用到一個叫做意向鎖的東東來快速判斷是否可以對某個表使用表鎖，

意向鎖是表級鎖，共有兩種：

• 意向共享鎖（Intention Shared Lock，IS 鎖）：事務有意向對表中的某些加共享鎖（S 鎖），加共享鎖前必須先取得該表的 IS 鎖，
• 意向排他鎖（Intention Exclusive Lock，IX 鎖）：事務有意向對表中的某些記錄加排他鎖（X 鎖），加排他鎖之前必須先取得該表的 IX 鎖，

意向鎖是有資料引擎自己維護的，用戶無法手動操作意向鎖，在為資料行加共享 / 排他鎖之前，InooDB 會先獲取該資料行所在在資料表的對應意向鎖，

意向鎖之間是互相兼容的，

意向鎖和共享鎖和排它鎖互斥（這里指的是表級別的共享鎖和排他鎖，意向鎖不會與行級的共享鎖和排他鎖互斥），

InnoDB 有哪幾類行鎖？

按鎖粒度分類，有行級鎖、表級鎖和頁級鎖，

1. 行級鎖是mysql中鎖定粒度最細的一種鎖，表示只針對當前操作的行進行加鎖，行級鎖能大大減少資料庫操作的沖突，其加鎖粒度最小，但加鎖的開銷也最大，行級鎖的型別主要有三類：
   • Record Lock，記錄鎖，也就是僅僅把一條記錄鎖上；
   • Gap Lock，間隙鎖，鎖定一個范圍，但是不包含記錄本身；
   • Next-Key Lock：Record Lock + Gap Lock 的組合，鎖定一個范圍，并且鎖定記錄本身，
2. 表級鎖是mysql中鎖定粒度最大的一種鎖，表示對當前操作的整張表加鎖，它實作簡單，資源消耗較少，被大部分mysql引擎支持，最常使用的MyISAM與InnoDB都支持表級鎖定，
3. 頁級鎖是 MySQL 中鎖定粒度介于行級鎖和表級鎖中間的一種鎖，表級鎖速度快，但沖突多，行級沖突少，但速度慢，因此，采取了折衷的頁級鎖，一次鎖定相鄰的一組記錄，

按鎖級別分類，有共享鎖、排他鎖和意向鎖，

1. 共享鎖又稱讀鎖，是讀取操作創建的鎖，其他用戶可以并發讀取資料，但任何事務都不能對資料進行修改（獲取資料上的排他鎖），直到已釋放所有共享鎖，
2. 排他鎖又稱寫鎖、獨占鎖，如果事務T對資料A加上排他鎖后，則其他事務不能再對A加任何型別的封鎖，獲準排他鎖的事務既能讀資料，又能修改資料，
3. 意向鎖是表級鎖，其設計目的主要是為了在一個事務中揭示下一行將要被請求鎖的型別，InnoDB 中的兩個表鎖：

意向共享鎖（IS）：表示事務準備給資料行加入共享鎖，也就是說一個資料行加共享鎖前必須先取得該表的IS鎖；

意向排他鎖（IX）：類似上面，表示事務準備給資料行加入排他鎖，說明事務在一個資料行加排他鎖前必須先取得該表的IX鎖，

意向鎖是 InnoDB 自動加的，不需要用戶干預，

對于INSERT、UPDATE和DELETE，InnoDB 會自動給涉及的資料加排他鎖；對于一般的SELECT陳述句，InnoDB 不會加任何鎖，事務可以通過以下陳述句顯式加共享鎖或排他鎖，

共享鎖：SELECT … LOCK IN SHARE MODE;

排他鎖：SELECT … FOR UPDATE;

什么是死鎖？如何防止死鎖？

什么是死鎖？

死鎖是指兩個或多個事務在同一資源上相互占用，并請求鎖定對方的資源，從而導致惡性回圈的現象，

如何防止死鎖？

• 盡量約定固定的順序訪問表，因為交叉訪問更容易造成事務等待回路，
• 盡量避免大事務，建議拆成多個小事務，因為大事務占用的鎖資源越多，越容易出現死鎖，
• 降低資料庫隔離級別，比如RR降低為RC，因為RR隔離級別，存在GAP鎖，死鎖概率大很多，
• 死鎖與索引是密不可分的，合理優化你的索引，死鎖概率降低，
• 如果業務處理不好可以用分布式事務鎖或者使用樂觀鎖

如何處理死鎖？

通過innodblockwait_timeout來設定超時時間，一直等待直到超時，

發起死鎖檢測，發現死鎖之后，主動回滾死鎖中的事務，不需要其他事務繼續，

什么是全域鎖？它的應用場景有哪些？

全域鎖就是對整個資料庫實體加鎖，它的典型使用場景就是做全庫邏輯備份，這個命令可以使用整個庫處于只讀狀態，使用該命令之后，資料更新陳述句，資料定義陳述句，更新類事務的提交陳述句等操作都會被阻塞，

使用全域鎖會導致的問題？

如果在主庫備份，在備份期間不能更新，業務停止，所以更新業務會處于等待狀態，

如果在從庫備份，在備份期間不能執行主庫同步的binlog，導致主從延遲，

樂觀鎖和悲觀鎖是什么？

資料庫中的并發控制是確保在多個事務同時存取資料庫中同一資料時不破壞事務的隔離性和統一性以及資料庫的統一性，樂觀鎖和悲觀鎖是并發控制主要采用的技術手段，

• 悲觀鎖：假定會發生并發沖突，會對操作的資料進行加鎖，直到提交事務，才會釋放鎖，其他事務才能進行修改，實作方式：使用資料庫中的鎖機制，
• 樂觀鎖：假設不會發生并發沖突，只在提交操作時檢查是否資料是否被修改過，給表增加version欄位，在修改提交之前檢查version與原來取到的version值是否相等，若相等，表示資料沒有被修改，可以更新，否則，資料為臟資料，不能更新，實作方式：樂觀鎖一般使用版本號機制或CAS演算法實作，

select for update加的是表鎖還是行鎖

需要情況討論：RR和RC隔離級別，還有查詢條件（唯一索引、主鍵、一般索引、無索引）

在RC隔離級別下

• 如果查詢條件是唯一索引，會加IX意向排他鎖（表級別的鎖，不影響插入）、兩把X排他鎖（行鎖，分別對應唯一索引，主鍵索引）
• 如果查詢條件是主鍵，會加IX意向排他鎖（表級別的鎖，不影響插入）、一把對應主鍵的X排他鎖（行鎖，會鎖住主鍵索引那一行），
• 如果查詢條件是普通索引，如果查詢命中記錄，會加IX意向排他鎖（表鎖）、兩把X排他鎖（行鎖，分別對應普通索引的X鎖，對應主鍵的X鎖）;如果沒有命中資料庫表的記錄，只加了一把IX意向排他鎖（表鎖，不影響插入）
• 如果查詢條件是無索引，會加兩把鎖，IX意向排他鎖（表鎖）、一把X排他鎖（行鎖，對應主鍵的X鎖），

查詢條件是無索引，為什么不鎖表呢？ MySQL會走聚簇(主鍵)索引進行全表掃描過濾，每條記錄都會加上X鎖，但是，為了效率考慮，MySQL在這方面進行了改進，在掃描程序中，若記錄不滿足過濾條件，會進行解鎖操作，同時優化違背了2PL原則，

在RR隔離級別

• 如果查詢條件是唯一索引，命中資料庫表記錄時，一共會加三把鎖：一把IX意向排他鎖 （表鎖，不影響插入），一把對應主鍵的X排他鎖（行鎖），一把對應唯一索引的X排他鎖 （行鎖），
• 如果查詢條件是主鍵，會加IX意向排他鎖（表級別的鎖，不影響插入）、一把對應主鍵的X排他鎖（行鎖，會鎖住主鍵索引那一行），
• 如果查詢條件是普通索引，命中查詢記錄的話，除了會加X鎖（行鎖），IX鎖（表鎖，不影響插入），還會加Gap 鎖（間隙鎖，會影響插入），
• 如果查詢條件是無索引，會加一個IX鎖（表鎖，不影響插入），每一行實際記錄行的X鎖，還有對應于supremum pseudo-record的虛擬全表行鎖，這種場景，通俗點講，其實就是鎖表了，

參考鏈接：https://juejin.cn/post/7199666255884009532

優化鎖方面有什么建議？

• 盡量使用較低的隔離級別，

• 精心設計索引， 并盡量使用索引訪問資料， 使加鎖更精確， 從而減少鎖沖突的機會，

• 選擇合理的事務大小，小事務發生鎖沖突的幾率也更小，

• 給記錄集顯示加鎖時，最好一次性請求足夠級別的鎖，比如要修改資料的話，最好直接申請排他鎖，而不是先申請共享鎖，修改時再請求排他鎖，這樣容易產生死鎖，

• 不同的程式訪問一組表時，應盡量約定以相同的順序訪問各表，對一個表而言，盡可能以固定的順序存取表中的行，這樣可以大大減少死鎖的機會，

• 不要申請超過實際需要的鎖級別，

• 除非必須，查詢時不要顯示加鎖， MySQL 的 MVCC 可以實作事務中的查詢不用加鎖，優化事務性能；

最后給大家分享一個Github倉庫，上面有大彬整理的300多本經典的計算機書籍PDF，包括C語言、C++、Java、Python、前端、資料庫、作業系統、計算機網路、資料結構和演算法、機器學習、編程人生等，可以star一下，下次找書直接在上面搜索，倉庫持續更新中~

Github地址：https://github.com/Tyson0314/java-books

標籤：Java

上一篇：確定了，今天帶一個看板娘回家

下一篇：面試官：怎么洗掉 HashMap 中的重復元素？第 3 種實作思路，99% 的人不會！