本文章向大家介紹MySQL鎖詳細講解，包括數據庫鎖基本知識、表鎖、表讀鎖、表寫鎖、行鎖、MVCC、事務的隔離級別、悲觀鎖、樂觀鎖、間隙鎖GAP、死鎖等等，需要的朋友可以參考一下

數據庫鎖知識

不少人在開發的時候，應該很少會注意到這些鎖的問題，也很少會給程序加鎖(除了庫存這些對數量準確性要求極高的情況下)，即使我們不會這些鎖知識，我們的程序在一般情況下還是可以跑得好好的。因為這些鎖數據庫隱式幫我們加了，只會在某些特定的場景下才需要手動加鎖。

對于UPDATE、DELETE、INSERT語句，InnoDB會自動給涉及數據集加排他鎖（X) MyISAM在執行查詢語句SELECT前，會自動給涉及的所有表加讀鎖，在執行增、刪、改操作前，會自動給涉及的表加寫鎖，這個過程并不需要用戶干預

表鎖

首先，從鎖的粒度，我們可以分成兩大類：
表鎖 :開銷小，加鎖快；不會出現死鎖；鎖定力度大，發生鎖沖突概率高，并發度最低
行鎖:開銷大，加鎖慢；會出現死鎖；鎖定粒度小，發生鎖沖突的概率低，并發度高 不同的存儲引擎支持的鎖粒度是不一樣的==：InnoDB行鎖和表鎖都支持、MyISAM只支持表鎖！InnoDB只有通過索引條件檢索數據才使用行級鎖==，否則，InnoDB使用表鎖也就是說，InnoDB的行鎖是基于索引的！

表鎖下又分為兩種模式： 表讀鎖（Table Read Lock）&& 表寫鎖（Table Write Lock）
從下圖可以清晰看到，在表讀鎖和表寫鎖的環境下：讀讀不阻塞，讀寫阻塞，寫寫阻塞！ 讀讀不阻塞：當前用戶在讀數據，其他的用戶也在讀數據，不會加鎖 讀寫阻塞：當前用戶在讀數據，其他的用戶不能修改當前用戶讀的數據，會加鎖！ 寫寫阻塞：當前用戶在修改數據，其他的用戶不能修改當前用戶正在修改的數據，會加鎖！

從上面已經看到了：讀鎖和寫鎖是互斥的，讀寫操作是串行。

• 如果某個進程想要獲取讀鎖，同時另外一個進程想要獲取寫鎖。在mysql中，寫鎖是優先于讀鎖的！
• 寫鎖和讀鎖優先級的問題是可以通過參數調節的：max_write_lock_count和low-priority-updates

注：

行鎖

InnoDB和MyISAM有兩個本質的區別：InnoDB支持行鎖、InnoDB支持事務

InnoDB實現了以下兩種類型的行鎖：

• 共享鎖（S鎖、讀鎖）：允許一個事務去讀一行，阻止其他事務獲得相同數據集的排他鎖。即多個客戶可以同時讀取同一個資源，但不允許其他客戶修改。
• 排他鎖（X鎖、寫鎖)：允許獲得排他鎖的事務更新數據，阻止其他事務取得相同數據集的讀鎖和寫鎖。寫鎖是排他的，寫鎖會阻塞其他的寫鎖和讀鎖。

另外，為了允許行鎖和表鎖共存，實現多粒度鎖機制，InnoDB還有兩種內部使用的意向鎖（Intention Locks），這兩種意向鎖都是表鎖：

• 意向共享鎖（IS）：事務打算給數據行加行共享鎖，事務在給一個數據行加共享鎖前必須先取得該表的IS鎖。
• 意向排他鎖（IX）：事務打算給數據行加行排他鎖，事務在給一個數據行加排他鎖前必須先取得該表的IX鎖。
• 意向鎖也是數據庫隱式幫我們做了，不需要程序員關心！

MVCC

MVCC(Multi-Version ConcurrencyControl)多版本并發控制，可以簡單地認為：MVCC就是行級鎖的一個變種(升級版)。在表鎖中我們讀寫是阻塞的，基于提升并發性能的考慮，MVCC一般讀寫是不阻塞的(很多情況下避免了加鎖的操作)。
可以簡單的理解為：對數據庫的任何修改的提交都不會直接覆蓋之前的數據，而是產生一個新的版本與老版本共存，使得讀取時可以完全不加鎖。

事務的隔離級別

事務的隔離級別就是通過鎖的機制來實現，鎖的應用最終導致不同事務的隔離級別，只不過隱藏了加鎖細節，事務的隔離級別有4種：

• Read uncommitted：會出現臟讀，不可重復讀，幻讀
• Read committed：會出現不可重復讀，幻讀
• Repeatable read：會出現幻讀(Mysql默認的隔離級別，但是Repeatable read配合gap鎖不會出現幻讀！)
• Serializable：串行，避免以上的情況

Read uncommitted： 出現的現象--->臟讀：一個事務讀取到另外一個事務未提交的數據，例子：A向B轉賬，A執行了轉賬語句，但A還沒有提交事務，B讀取數據，發現自己賬戶錢變多了！B跟A說，我已經收到錢了。A回滾事務【rollback】，等B再查看賬戶的錢時，發現錢并沒有多...

Read committed： 出現的現象--->不可重復讀：一個事務讀取到另外一個事務已經提交的數據，也就是說一個事務可以看到其他事務所做的修改，例如：A查詢數據庫得到數據，B去修改數據庫的數據，導致A多次查詢數據庫的結果都不一樣【危害：A每次查詢的結果都是受B的影響的，那么A查詢出來的信息就沒有意思了】

Repeatable read： 避免不可重復讀是事務級別的快照！每次讀取的都是當前事務的版本，即使被修改了，也只會讀取當前事務版本的數據

至于虛讀(幻讀)：是指在一個事務內讀取到了別的事務插入的數據，導致前后讀取不一致。和不可重復讀類似，但虛讀(幻讀)會讀到其他事務的插入的數據，導致前后讀取不 一致，幻讀的重點在于新增或者刪除(數據條數變化)，不可重復讀的重點是修改，幻讀和不可重復的區別？

樂觀鎖和悲觀鎖

無論是Read committed還是Repeatable read隔離級別，都是為了解決讀寫沖突的問題，現在考慮一個問題：有一張數據庫表USER，只有id、name字段，現在有2個請求同時操作表A，過程如下：（模擬更新丟失，雖然不是很恰當）
　1. 操作1查詢出name="zhangsan"
　2. 操作2也查詢出name="zhangsan"
　3. 操作1把name字段數據修改成lisi并提交
　4. 操作2把name字段數據修改為wangwu并提交

那么操作1的更新丟失啦，即一個事務的更新覆蓋了其它事務的更新結果，解決上述更新丟失的方式有如下3種：

• 使用Serializable隔離級別，事務是串行執行的！
• 樂觀鎖
• 悲觀鎖

悲觀鎖

我們使用悲觀鎖的話其實很簡單(手動加行鎖就行了)：select * from xxxx for update，在select 語句后邊加了for update相當于加了排它鎖(寫鎖)，加了寫鎖以后，其他事務就不能對它修改了！需要等待當前事務修改完之后才可以修改.也就是說，如果操作1使用select ... for update，操作2就無法對該條記錄修改了，即可避免更新丟失。

樂觀鎖

樂觀鎖不是數據庫層面上的鎖，需要用戶手動去加的鎖。一般我們在數據庫表中添加一個版本字段version來實現，例如操作1和操作2在更新User表的時，執行語句如下：

update A set Name=lisi,version=version+1 where ID=#{id} and version=#{version}，

此時即可避免更新丟失。

間隙鎖GAP

當我們用范圍條件檢索數據而不是相等條件檢索數據，并請求共享或排他鎖時，InnoDB會給符合范圍條件的已有數據記錄的索引項加鎖；對于鍵值在條件范圍內但并不存在 的記錄，叫做“間隙（GAP)”。InnoDB也會對這個“間隙”加鎖，這種鎖機制就是所謂的間隙鎖。例子：假如emp表中只有101條記錄，其empid的值分別是1,2,...,100,101

Select * from emp where empid > 100 for update;

上面是一個范圍查詢，InnoDB不僅會對符合條件的empid值為101的記錄加鎖，也會對empid大于101（這些記錄并不存在）的“間隙”加鎖

InnoDB使用間隙鎖的目的有2個：

• 為了防止幻讀(上面也說了，Repeatable read隔離級別下再通過GAP鎖即可避免了幻讀)
• 滿足恢復和復制的需要：MySQL的恢復機制要求在一個事務未提交前，其他并發事務不能插入滿足其鎖定條件的任何記錄，也就是不允許出現幻讀

死鎖

并發的問題就少不了死鎖，在MySQL中同樣會存在死鎖的問題

鎖總結

表鎖其實我們程序員是很少關心它的：

• 在MyISAM存儲引擎中，當執行SQL語句的時候是自動加的。
• 在InnoDB存儲引擎中，如果沒有使用索引，表鎖也是自動加的。

現在我們大多數使用MySQL都是使用InnoDB，InnoDB支持行鎖：

• 共享鎖--讀鎖--S鎖
• 排它鎖--寫鎖--X鎖

在默認的情況下，select是不加任何行鎖的~事務可以通過以下語句顯示給記錄集加共享鎖或排他鎖。

• 共享鎖（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE
• 排他鎖（X)：SELECT * FROM table_name WHERE ... FOR UPDATE

InnoDB基于行鎖還實現了MVCC多版本并發控制，MVCC在隔離級別下的Read committed和Repeatable read下工作。MVCC實現了讀寫不阻塞