漫談MySQL的鎖機制

阿新 • • 發佈：2019-12-31

1 MySQL的三種鎖

1.1 表鎖

開銷小，加鎖快
不會出現死鎖
鎖定粒度大，發生鎖衝突的概率最高，併發度最低

1.2 行鎖

開銷大，加鎖慢
會出現死鎖
鎖定粒度小，發生鎖衝突的概率最低，併發度最高

1.3 頁鎖

開銷和加鎖時間介於表鎖和行鎖之間
會出現死鎖
鎖定粒度介於表鎖和行鎖之間，併發度一般

1.4 引擎與鎖

MyISAM和MEMORY支援表鎖
BDB支援頁鎖,也支援表鎖
Innodb既支援行鎖,也支援表鎖,預設行鎖

1.5 查詢表鎖爭用情況

檢查table_locks_waited和table_locks_immediate狀態變數分析

table_locks_immediate : 可以立即獲取鎖的次數
table_locks_waited : 不能立即獲取鎖，需要等待鎖的次數

table_locks_waited 的值越高，則說明存在嚴重的表級鎖的爭用情況

2 表鎖模式（MyISAM)

ＭySQL的表鎖有兩種模式

表共享讀鎖（Table Read Lock）
表獨佔寫鎖（Table Write Lock）

2.1 表鎖相容性

鎖模式的相容如下表

是否相容	請求none	請求讀鎖	請求寫鎖
當前處於讀鎖	是	是	否
當前處於寫鎖	是	否	否

可見，對ＭyISAM表的讀操作,不會阻塞其他使用者對同一表的讀請求,但會阻塞對同一表的寫請求;

對ＭyISAM表的寫操作,則會阻塞其他使用者對同一表的讀和寫請求;

ＭyISAM表的讀和寫操作之間,以及寫和寫操作之間是序列的!(當某一執行緒獲得對一個表的寫鎖後,只有持有鎖的執行緒可以對錶進行更新操作.其他執行緒的讀、寫操作都會等待,直到鎖被釋放為止)

2.2 如何加表鎖

對於 MyISAM 引擎

執行select前,會自動給涉及的所有表加讀
執行更新（update,delete,insert)會自動給涉及到的表加寫

不需要使用者直接顯式用lock table命令

對於給MyISAM顯式加鎖，一般是為了在一定程度上模擬事務操作，實現對某一個時間點多個表一致性讀取

2.2.1 例項

訂單表 - orders
記錄各訂單的總金額total
訂單明細表 - order_detail
記錄各訂單每一產品的金額小計subtotal

假設我們需要檢查這兩個表的金額合計是否相符,可能就需要執行如下兩條SQL

圖片上傳失敗...(image-3017e3-1547370332969)

這時,如果不先給這兩個表加鎖,就可能產生錯誤的結果;

因為第一條語句執行過程中,order_detail表可能已經發生了改變.

因此,正確寫法應該如下

圖片上傳失敗...(image-8081d7-1547370332969)

2.2.2 注意點

上面的例子在LOCK TABLES時加了‘local’選項，其作用就是在滿足MyISAM表併發插入條件的情況下，允許其他使用者在表尾插入記錄
在用LOCK TABLES給表顯式加表鎖時，必須同時取得所有涉及表的鎖，並且MySQL支援鎖升級;
也就是說，在執行LOCK TABLES後，只能訪問顯式加鎖的這些表，不能訪問未加鎖的表；
同時，如果加的是讀鎖，那麼只能執行查詢操作，而不能執行更新操作
其實，在自動加鎖的情況下也基本如此，MySQL會一次獲得SQL語句所需要的全部鎖.這也正是MyISAM表不會出現死鎖（Deadlock Free）的原因

session1	session2
獲得表 `film_text` 的讀鎖 lock table film_text read;
可select * from film_text	可select * from film_text
不能查詢沒有鎖定的表 :select * from film	可查詢/更新未鎖定的表: select * from film
插入或更新鎖定表會提示錯誤 update...from film_text	更新鎖定表會等待 update...from film_text
釋放鎖 unlock tables	等待
	獲得鎖，更新成功

2.3 tips

當使用lock tables時,不僅需要一次鎖定用到的所有表

且同一表在SQL語句中出現多少次,就要通過與SQL語句中別名鎖多少次

lock table actor read複製程式碼

會提示錯誤

select a.first_name.....複製程式碼

需要對別名分別鎖定

lock table actor as a read,actor as b read;複製程式碼

3 MyISAM的併發鎖

在一定條件下，MyISAM也支援併發插入和讀取

3.1 系統變數 : concurrent_insert

控制其併發插入的行為,其值分別可以為

0 不允許併發插入,所有插入對錶加互斥鎖
1 只要表中無空洞,就允許併發插入.
MyISAM允許在一個讀表的同時，另一個程式從表尾插入記錄(MySQL的預設設定)
2 無論MyISAM表中有無空洞,都強制在表尾併發插入記錄
若無讀執行緒,新行插入空洞中

可以利用MyISAM的併發插入特性，來解決應用中對同表查詢和插入的鎖爭用

例如,將concurrent_insert系統變數設為2，總是允許併發插入;

同時,通過定期在系統空閒時段執行OPTIONMIZE TABLE語句來整理空間碎片，收到因刪除記錄而產生的中間空洞

刪除操作不會重整整個表,只是把行標記為刪除,在表中留下空洞

MyISAM傾向於在可能時填滿這些空洞,插入時就會重用這些空間,無空洞則把新行插到表尾

3.2 MyISAM的鎖排程

MyISAM的讀和寫鎖互斥,讀操作序列的

一個程式請求某個MyISAM表的讀鎖,同時另一個程式也請求同表的寫鎖，MySQL如何處理呢？
寫程式先獲得鎖!!!
不僅如此,即使讀程式先請求先到鎖等待佇列,寫請求後到,寫鎖也會插到讀請求之前!!!

這是因為MySQL認為寫請求一般比讀請求重要

這也正是MyISAM表不適合有大量更新 / 查詢操作應用的原因

大量的更新操作會造成查詢操作很難獲得讀鎖,從而可能永遠阻塞

幸好,我們可以通過一些設定來調節MyISAM的排程行為

指定啟動引數low-priority-updates
使MyISAM引擎預設給予讀請求以優先權利
執行命令SET LOW_PRIORITY_UPDATES=1
使該連線發出的更新請求優先順序降低
指定INSERT、UPDATE、DELETE語句的LOW_PRIORITY屬性
降低該語句的優先順序

雖然上面3種方法都是要麼更新優先，要麼查詢優先，但還是可以用其來解決查詢相對重要的應用（如使用者登入系統）中，讀鎖等待嚴重的問題

另外，MySQL也提供了一種折中的辦法來調節讀寫衝突;

即給系統引數max_write_lock_count設定一個合適的值;

當一個表的讀鎖達到這個值後，MySQL便暫時將寫請求的優先順序降低，給讀程式一定獲得鎖的機會

* * *

4 InnoDB鎖

InnoDB與MyISAM的最大不同有兩點

支援事務
採用行鎖

行級鎖和表級鎖本來就有許多不同之處，另外，事務的引入也帶來了一些新問題

4.1 事務

一組SQL語句組成的邏輯處理單元

原子性(Actomicity)
事務是一個原子操作單元，其對資料的修改，要麼全都執行，要麼全都不執行
一致性（Consistent）
在事務開始和完成時，資料都必須保持一致狀態
這意味著所有相關的資料規則都必須應用於事務的修改，以保持完整性
事務結束時，所有的內部資料結構（如B樹索引或雙向連結串列）也都必須是正確的
隔離性（Isolation）
一個事務所做的修改在最終提交前對其他事務不可見
永續性（Durability）
一旦事務提交，它對於資料的修改會持久化到DB

4.2 事務的問題

相對於序列處理來說，併發事務處理能大大增加資料庫資源的利用率，提高資料庫系統的事務吞吐量，從而可以支援可以支援更多的使用者

但併發事務處理也會帶來一些問題，主要包括以下幾種情況

更新丟失（Lost Update）
當多個事務選擇同一行,然後基於最初選定值更新該行時，由於事務隔離性，最後的更新覆蓋了其他事務所做的更新.
例如，兩個編輯人員製作了同一檔案的電子副本。每個編輯人員獨立地更改其副本，然後儲存更改後的副本，這樣就覆蓋了原始檔案。最後儲存其更改儲存其更改副本的編輯人員覆蓋另一個編輯人員所做的修改;
如果在一個編輯人員完成並提交事務之前，另一個編輯人員不能訪問同一檔案，則可避免此問題
髒讀（Dirty Reads）
一個事務正在對一條記錄做修改，在該事務提交前，這條記錄的資料就處於不一致狀態
這時，另一個事務也來讀取同一條記錄，讀取了這些未提交的資料
不可重複讀（Non-Repeatable Reads）
一個事務在讀取某些資料已經發生了改變、或某些記錄已經被刪除
幻讀（Phantom Reads)
一個事務按相同的查詢條件重新讀取以前檢索過的資料，卻發現其他事務插入了滿足其查詢條件的新資料

4.3 事務隔離級別

在併發事務的問題中，“更新丟失”通常應該是完全避免的;

但防止更新丟失,並不能單靠資料庫事務控制器來解決,需要應用程式對要更新的資料加必要的鎖來解決,因此，防止更新丟失應該是應用的責任

“髒讀”、“不可重複讀”和“幻讀”,其實都是資料庫讀一致性問題,必須由資料庫提供一定的事務隔離機制來解決

資料庫實現事務隔離的方式，基本可以分為以下兩種

在讀取資料前,對其加鎖,防止其他事務對資料進行修改
不加任何鎖,通過一定機制生成一個資料請求時間點的一致性資料快照,並用這個快照來提供一定級別(語句級或事務級)的一致性讀取.
從使用者的角度,好像是資料庫可以提供同一資料的多個版本,因此,這種技術叫做資料多版本併發控制（ＭultiVersion Concurrency Control,MVCC），也經常稱為多版本資料庫

資料庫的事務隔離級別越嚴格,併發副作用越小,但付出的代價也越大

因為事務隔離實質上就是使事務在一定程度上“序列化”進行,這顯然與“併發”矛盾

為瞭解決“隔離”與“併發”的矛盾，ANSI SQL定義了４種隔離級別

隔離級別/讀資料一致性及允許的併發副作用	讀資料一致性	髒讀	不可重複讀	幻讀
未提交讀（Read uncommitted）	最低階別，只能保證不讀取物理上損壞的資料	是	是	是
已提交度（Read committed）	語句級	否	是	是
可重複讀（Repeatable read）	事務級	否	否	是
可序列化（Serializable）	最高階別，事務級	否	否	否

檢視Innodb行鎖爭用情況

如果發現爭用比較嚴重，如Innodb_row_lock_waits和Innodb_row_lock_time_avg的值比較高

查詢information_schema相關表來檢視鎖情況

設定Innodb monitors

進一步觀察發生鎖衝突的表，資料行等，並分析鎖爭用的原因

停止監視器

預設情況每15秒會向日志中記錄監控的內容;

如果長時間開啟會導致.err檔案變得非常巨大;

所以確認原因後,要刪除監控表關閉監視器,或者通過使用--console選項來啟動伺服器以關閉寫日誌功能

4.4 InnoDB的行鎖

InnoDB支援以下兩種型別的行鎖

共享鎖（讀鎖S）
若事務 T 對資料物件 A 加了 S 鎖;
則事務 T 可以讀 A 但不能修改 A;
其它事務只能再對它加 S 鎖,而不能加 X 鎖,直到 T 釋放 A 上的 S 鎖;
這保證了,其他事務可以讀 A，但在事務 T 釋放 S 鎖之前，不能對 A 做任何修改操作.
排他鎖（寫鎖X）
若事務 T 對資料物件A加 X 鎖;
事務 T 可以讀 A 也可以修改 A;
其他事務不能對 A 加任何鎖,直到 T 釋放 A 上的鎖;
這保證了,其他事務在 T 釋放 A 上的鎖之前不能再讀取和修改 A .

MySQL InnoDB預設行級鎖

行級鎖都是基於索引的,若一條SQL語句用不到索引是不會使用行級鎖的,會使用表級鎖把整張表鎖住

為了允許行/表鎖共存,實現多粒度鎖機制,InnoDB還有兩種內部使用的意向鎖（Intention Locks）

這兩種意向鎖都是表鎖

意向共享鎖（IS）
事務打算給資料行共享鎖;
事務在給一個資料行加共享鎖前必須先取得該表的IS鎖
意向排他鎖（IX）
事務打算給資料行加排他鎖;
事務在給一個資料行加排他鎖前必須先取得該表的IX鎖

當前鎖/是否相容/請求鎖	X	IX	S	IS
X	衝突	衝突	衝突	衝突
IX	衝突	相容	衝突	相容
S	衝突	衝突	相容	相容
IS	衝突	相容	相容	相容

如果一個事務請求的鎖模式與當前鎖相容，InnoDB就請求的鎖授予該事務;

反之，如果兩者兩者不相容，該事務就要等待鎖釋放

意向鎖是InnoDB自動加的，不需使用者幹預.

對於UPDATE、DELETE和INSERT語句，InnoDB會自動給涉及及資料集加排他鎖（Ｘ）;

對於普通SELECT語句，InnoDB不會加任何鎖.

對於SELECT語句,可以通過以下語句顯式地給記錄加讀/寫鎖

共享鎖（Ｓ）
排他鎖（X）

共享鎖語句主要用在需要資料依存關係時確認某行記錄是否存在;

並確保沒有人對這個記錄UPDATE或DELETE.

但如果當前事務也需要對該記錄進行更新,則很有可能造成死鎖;

對於鎖定行記錄後需要進行更新操作的應用,應該使用排他鎖語句.

4.5 例項

4.5.1 Innodb共享鎖

session_1	session_2
set autocommit=0,select * from actor where id =1	set autocommit=0,select * from actor where id =1
當前seesion對id為1的記錄加入共享鎖 select * from actor where id =1 lock in share mode
	其他seesion仍然可以查詢，並對該記錄加入 select * from actor where id =1 lock in share mode
當前session對鎖定的記錄進行更新，等待鎖 update。。。where id=1
	當前session對鎖定記錄進行更新，則會導致死鎖退出 update。。。where id=1

| 獲得鎖，更新成功 |

4.5.2 Innodb排他鎖

session_1	session_2
set autocommit=0,select * from actor where id =1
當前seesion對id為1的記錄加入for update 共享鎖 select * from actor where id =1 for update
	可查詢該記錄select from actor where id =1,但是不能再記錄共享鎖，會等待獲得鎖select from actor where id =1 for update
更新後釋放鎖 update。。。 commit
	其他session，獲得鎖，得到其他seesion提交的記錄

4.6 行鎖的實現

行鎖是通過給索引上的索引項加鎖來實現

如果沒有索引，InnoDB將通過隱藏的聚簇索引來對記錄加鎖

Record Locks:對索引項加鎖
Gap lock:對索引項之的“間隙“，第一條記錄前的”間隙“，或最後一條記錄後的”間隙“，加鎖
Next-key lock：前兩種的組合，對記錄及其前面的間隙加鎖

行鎖實現特點意味著：

如果不通過索引條件檢索資料,那麼Innodb將對錶的所有記錄加鎖，和表鎖一樣

間隙鎖（Next-Key鎖）

當我們用範圍條件而不是相等條件檢索資料,並請求共享或排他鎖時,InnoDB會給符合條件的已有資料的索引項加鎖;

對於鍵值在條件範圍內但並不存在的記錄,叫做“間隙(GAP)”,InnoDB也會對這個“間隙”加鎖,這種鎖機制就是所謂的間隙鎖（Next-Key鎖）.

舉例來說，假如emp表中只有101條記錄，其empid的值分別是1,2,...,100,101，下面的SQL：

InnoDB 不僅會對符合條件的 empid 值為 101 的記錄加鎖;

也會對 empid大於101（這些記錄並不存在）的“間隙”加鎖

間隙鎖的目的

防止幻讀,以滿足相關隔離級別的要求
對於上例,若不使用間隙鎖,如果其他事務插入 empid 大於 100 的任何記錄,;
那麼本事務如果再次執行上述語句,就會發生幻讀
滿足其恢復和複製的需要
在使用範圍條件檢索並鎖定記錄時;
InnoDB 這種加鎖機制會阻塞符合條件範圍內鍵值的併發插入,這往往會造成嚴重的鎖等待;
因此,在實際開發中,尤其是併發插入較多的應用;
我們要儘量優化業務邏輯,儘量使用相等條件來訪問更新資料,避免使用範圍條件.

4.7 when 使用表鎖

對於InnoDB,在絕大部分情況下都應該使用行鎖

因為事務,行鎖往往是我們選擇InnoDB的理由

但在個別特殊事務中,也可以考慮使用表鎖

事務需要更新大部分資料，表又較大
若使用預設的行鎖,不僅該事務執行效率低(因為需要對較多行加鎖,加鎖是需要耗時的);
而且可能造成其他事務長時間鎖等待和鎖衝突;
這種情況下可以考慮使用表鎖來提高該事務的執行速度
事務涉及多個表，較複雜，很可能引起死鎖，造成大量事務回滾
這種情況也可以考慮一次性鎖定事務涉及的表，從而避免死鎖、減少資料庫因事務回滾帶來的開銷

當然，應用中這兩種事務不能太多，否則，就應該考慮使用ＭyISAＭ

在InnoDB下,使用表鎖要注意

使用LOCK TALBES雖然可以給InnoDB加表鎖
表鎖不是由InnoDB引擎層管理的,而是由其上一層ＭySQL Server負責;
僅當autocommit=0、innodb_table_lock=1（預設設定）,InnoDB 引擎層才知道MySQL加的表鎖,ＭySQL Server才能感知InnoDB加的行鎖;
這種情況下，InnoDB才能自動識別涉及表鎖的死鎖
否則，InnoDB將無法自動檢測並處理這種死鎖
在用LOCK TALBES對InnoDB鎖時要注意,要將autocommit設為0，否則ＭySQL不會給表加鎖
事務結束前,不要用UNLOCK TALBES釋放表鎖,因為它會隱式地提交事務
COMMIT或ROLLBACK不能釋放用LOCK TALBES加的表鎖，必須用UNLOCK TABLES釋放表鎖，正確的方式見如下語句
需要寫表t1並從表t讀

5 死鎖

ＭyISAM表鎖是deadlock free的，這是因為ＭyISAM總是一次性獲得所需的全部鎖，要麼全部滿足，要麼等待，因此不會出現死鎖

但在InnoDB中，除單個SQL組成的事務外，鎖是逐步獲得的，這就決定了InnoDB發生死鎖是可能的

發生死鎖後，InnoDB一般都能自動檢測到，並使一個事務釋放鎖並退回，另一個事務獲得鎖，繼續完成事務

但在涉及外部鎖，或涉及鎖的情況下，InnoDB並不能完全自動檢測到死鎖
這需要通過設定鎖等待超時引數innodb_lock_wait_timeout來解決
需要說明的是，這個引數並不是隻用來解決死鎖問題，在併發訪問比較高的情況下，如果大量事務因無法立即獲取所需的鎖而掛起，會佔用大量計算機資源，造成嚴重效能問題，甚至拖垮資料庫
我們通過設定合適的鎖等待超時閾值，可以避免這種情況發生。

通常來說，死鎖都是應用設計的問題，通過調整業務流程、資料庫物件設計、事務大小、以及訪問資料庫的SQL語句，絕大部分都可以避免

下面就通過例項來介紹幾種死鎖的常用方法。

應用中，不同的程式會併發存取多個表
儘量約定以相同的順序訪問表
程式批處理資料時
事先對資料排序,保證每個執行緒按固定的順序來處理記錄
在事務中,要更新記錄
應直接申請排他鎖,而不應該先申請共享鎖
在可重複讀下,如果兩個執行緒同時對相同條件記錄用SELECT...ROR UPDATE加排他寫鎖
在沒有符合該記錄情況下，兩個執行緒都會加鎖成功
程式發現記錄尚不存在，就試圖插入一條新記錄，如果兩個執行緒都這麼做，就會出現死鎖
這種情況下，將隔離級別改成READ COMMITTED，就可以避免問題
當隔離級別為READ COMMITED時，如果兩個執行緒都先執行SELECT...FOR UPDATE
判斷是否存在符合條件的記錄，沒有 -> 插入記錄;
此時，只有一個執行緒能插入成功，另一個執行緒會出現鎖等待.
當第１個執行緒提交後，第２個執行緒會因主鍵重出錯，但雖然這個執行緒出錯了，卻會獲得一個排他鎖！這時如果有第３個執行緒又來申請排他鎖，也會出現死鎖.
對於這種情況，可以直接做插入操作，然後再捕獲主鍵重異常，或者在遇到主鍵重錯誤時，總是執行ROLLBACK釋放獲得的排他鎖

如果出現死鎖，可以用SHOW INNODB STATUS命令來確定最後一個死鎖產生的原因和改進措施。

6 總結

6.1 MyISAM的表鎖

共享讀鎖之間是相容的,但共享讀鎖和排他寫鎖之間,以及排他寫鎖之間互斥,即讀寫序列
在一定條件下,ＭyISAM允許查詢/插入併發,可利用這一點來解決應用中對同一表查詢/插入的鎖爭用問題
ＭyISAM預設的鎖排程機制是寫優先,這並不一定適合所有應用,使用者可以通過設定LOW_PRIPORITY_UPDATES引數或在INSERT、UPDATE、DELETE語句中指定LOW_PRIORITY選項來調節讀寫鎖的爭用
由於表鎖的鎖定粒度大,讀寫又是序列的,因此如果更新操作較多,ＭyISAM表可能會出現嚴重的鎖等待,可以考慮採用InnoDB表來減少鎖衝突