一盗扒、什么是死鎖
官方定義如下：兩個事務都持有對方需要的鎖，并且在等待對方釋放缀去，并且雙方都不會釋放自己的鎖侣灶。
這個就好比你有一個人質，對方有一個人質缕碎，你們倆去談判說換人褥影。你讓對面放人，對面讓你放人咏雌。
二凡怎、為什么會形成死鎖
看到這里，也許你會有這樣的疑問赊抖，事務和談判不一樣统倒，為什么事務不能使用完鎖之后立馬釋放呢？居然還要操作完了之后一直持有鎖氛雪？這就涉及到 MySQL 的并發(fā)控制了房匆。
MySQL的并發(fā)控制有兩種方式，一個是 MVCC报亩，一個是兩階段鎖協(xié)議浴鸿。那么為什么要并發(fā)控制呢？是因為多個用戶同時操作 MySQL 的時候捆昏，為了提高并發(fā)性能并且要求如同多個用戶的請求過來之后如同串行執(zhí)行的一樣（可串行化調(diào)度）赚楚。具體的并發(fā)控制這里不再展開毙沾。咱們繼續(xù)深入討論兩階段鎖協(xié)議骗卜。
兩階段鎖協(xié)議（2PL）
官方定義：
兩階段鎖協(xié)議是指所有事務必須分兩個階段對數(shù)據(jù)加鎖和解鎖，在對任何數(shù)據(jù)進行讀、寫操作之前寇仓，事務首先要獲得對該數(shù)據(jù)的封鎖举户；在釋放一個封鎖之后，事務不再申請和獲得任何其他封鎖遍烦。
對應到 MySQL 上分為兩個階段：
- 擴展階段（事務開始后俭嘁，commit 之前）：獲取鎖
- 收縮階段（commit 之后）：釋放鎖
就是說呢，只有遵循兩段鎖協(xié)議服猪，才能實現(xiàn) 可串行化調(diào)度供填。
但是兩階段鎖協(xié)議不要求事務必須一次將所有需要使用的數(shù)據(jù)加鎖，并且在加鎖階段沒有順序要求罢猪，所以這種并發(fā)控制方式會形成死鎖近她。
三、MySQL 如何處理死鎖膳帕？
MySQL有兩種死鎖處理方式：
- 等待粘捎，直到超時（innodb_lock_wait_timeout=50s）。
- 發(fā)起死鎖檢測危彩，主動回滾一條事務攒磨，讓其他事務繼續(xù)執(zhí)行（innodb_deadlock_detect=on）。
由于性能原因汤徽，一般都是使用死鎖檢測來進行處理死鎖娩缰。
死鎖檢測
死鎖檢測的原理是構建一個以事務為頂點、鎖為邊的有向圖谒府，判斷有向圖是否存在環(huán)漆羔，存在即有死鎖。
回滾
檢測到死鎖之后狱掂，選擇插入更新或者刪除的行數(shù)最少的事務回滾演痒，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段來判斷。
四趋惨、如何避免發(fā)生死鎖
收集死鎖信息：
- 利用命令
SHOW ENGINE INNODB STATUS查看死鎖原因鸟顺。 - 調(diào)試階段開啟 innodb_print_all_deadlocks，收集所有死鎖日志器虾。
減少死鎖：
- 使用事務讯嫂，不使用
lock tables。 - 保證沒有長事務兆沙。
- 操作完之后立即提交事務欧芽，特別是在交互式命令行中。
- 如果在用
(SELECT ... FOR UPDATE or SELECT ... LOCK IN SHARE MODE)葛圃，嘗試降低隔離級別千扔。 - 修改多個表或者多個行的時候憎妙，
將修改的順序保持一致。 - 創(chuàng)建索引曲楚，可以使創(chuàng)建的鎖更少厘唾。
- 最好不要用
(SELECT ... FOR UPDATE or SELECT ... LOCK IN SHARE MODE)。 - 如果上述都無法解決問題龙誊，那么嘗試使用
lock tables t1, t2, t3鎖多張表
