官方定義如下：兩個事務都持有對方需要的鎖，并且在等待對方釋放，并且雙方都不會釋放自己的鎖。
創(chuàng)新互聯(lián)專注于企業(yè)成都營銷網站建設、網站重做改版、荷塘網站定制設計、自適應品牌網站建設、H5建站、商城網站建設、集團公司官網建設、外貿網站制作、高端網站制作、響應式網頁設計等建站業(yè)務，價格優(yōu)惠性價比高，為荷塘等各大城市提供網站開發(fā)制作服務。
這個就好比你有一個人質，對方有一個人質，你們倆去談判說換人。你讓對面放人，對面讓你放人。
看到這里，也許你會有這樣的疑問，事務和談判不一樣，為什么事務不能使用完鎖之后立馬釋放呢？居然還要操作完了之后一直持有鎖？這就涉及到 MySQL 的并發(fā)控制了。
MySQL的并發(fā)控制有兩種方式，一個是 MVCC，一個是兩階段鎖協(xié)議。那么為什么要并發(fā)控制呢？是因為多個用戶同時操作 MySQL 的時候，為了提高并發(fā)性能并且要求如同多個用戶的請求過來之后如同串行執(zhí)行的一樣（ 可串行化調度 ）。具體的并發(fā)控制這里不再展開。咱們繼續(xù)深入討論兩階段鎖協(xié)議。
官方定義：
對應到 MySQL 上分為兩個階段：
就是說呢，只有遵循兩段鎖協(xié)議，才能實現 可串行化調度 。
但是兩階段鎖協(xié)議不要求事務必須一次將所有需要使用的數據加鎖，并且在加鎖階段沒有順序要求，所以這種并發(fā)控制方式會形成死鎖。
MySQL有兩種死鎖處理方式：
由于性能原因，一般都是使用死鎖檢測來進行處理死鎖。
死鎖檢測的原理是構建一個以事務為頂點、鎖為邊的有向圖，判斷有向圖是否存在環(huán)，存在即有死鎖。
檢測到死鎖之后，選擇插入更新或者刪除的行數最少的事務回滾，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段來判斷。
MySQL如何處理死鎖
是不是報了
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
的錯誤?
如果是的話，那么應該是有別的程序，也在更新這個表。
你需要確定另外一個程序處理的順序。
然后想辦法讓你的同步程序，與那個程序，錯開時間運行。
這個問題，問的就有問題，你對同一條記錄，同時想將use設置成1或2，業(yè)務邏輯就有問題啊。我原來處理過類似的問題，介紹一下我的處理方式，在use表中，增加一個字段b，默認值是0，在事物一開始的時候，先將你要處理的那條記錄的b值，設置成1，再事物全都處理完畢后，在將1更新成0。如果事物一開始發(fā)現這條記錄的b值是1，則直接提示用戶，正在對同一條數據進行處理，請稍后在試，代碼里直接就return了，不往下進行。
說白了，就是用一個字段，把一條記錄鎖住，事物一開始先判斷鎖沒鎖，如果鎖了就提示用戶，如果沒鎖，就鎖住，然后向下進行，但是，無論是正常處理完，還是回滾，或者是拋出異常，都不要忘了把鎖解開。
鎖是需要事務結束后才釋放的。
一個是 MVCC，一個是兩階段鎖協(xié)議。
為什么要并發(fā)控制呢？是因為多個用戶同時操作 MySQL 的時候，為了提高并發(fā)性能并且要求如同多個用戶的請求過來之后如同串行執(zhí)行的一樣（為了解決臟讀、不可重復讀、幻讀）
官方定義：
兩階段鎖協(xié)議是指所有事務必須分兩個階段對數據加鎖和解鎖，在對任何數據進行讀、寫操作之前，事務首先要獲得對該數據的封鎖；在釋放一個封鎖之后，事務不再申請和獲得任何其他封鎖。
對應到 MySQL 上分為兩個階段：
但是兩階段鎖協(xié)議不要求事務必須一次將所有需要使用的數據加鎖（innodb在需要的索引列數據才鎖行），并且在加鎖階段沒有順序要求，所以這種并發(fā)控制方式會形成死鎖。
MySQL有兩種死鎖處理方式：
死鎖檢測 （默認開啟）
死鎖檢測的原理是構建一個以事務為頂點、鎖為邊的有向圖，判斷有向圖是否存在環(huán)，存在即有死鎖。
回滾
檢測到死鎖之后，選擇插入更新或者刪除的行數最少的事務回滾，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段來判斷。
收集死鎖信息：
減少死鎖：
死鎖解決：
重慶分公司
重慶分公司
