目錄

• 1.問題出現：
• 2.分析解決
• 3.解決方案：

1.問題出現：

在測試階段，大數據并發的情況下，發現sql語句造成表的死鎖，過一段時間，死鎖消失。于是進行排查

報錯如下：

對應的sql語句如下：

    @Insert("replace into ${tableName}( windcode,date, \n" +    "      code, high, open, low, \n" +    "      `close`, volume, turnover,gtm_modify) "    + "values (#{obj.windcode},#{obj.date},#{obj.code},#{obj.high},#{obj.open},#{obj.low},#{obj.close},#{obj.volume},#{obj.turnover},#{obj.updateTime})" )    int insertOne(@Param("obj") KDTO obj, @Param("tableName") String tableName);

在排除了數據問題和線程重復調用以后，我們關注了一下sql語句本身。 看了網上很多經驗分享，覺得問題可能出現在 Replace Into 語句上。

2.分析解決

首先我們分析一下為什么并發replace into導致MySQL死鎖

Replace into 一般作用是，當存在沖突時，會把舊記錄替換成新的記錄。也就是說這條語句執行，分為了兩個大步：判斷和執行

1.判斷：

首先判斷我們需要操作的記錄是否存在（根據主鍵或者唯一索引判斷）

2.操作：

• 針對不存在的記錄，語句會執行insert，插入操作。
• 針對已經存在的記錄，語句可以拆分為delete+insert操作

測試：

建立表

插入數據：

我們使用replace into語句去執行一個已經存在的數據：

可以清楚的發現，影響的行數是兩行

第一行的數據被修改了

我們使用replace into語句去執行一個不存在的數據：

可以清楚的發現，影響的行數是一行

執行了插入操作：

邏輯非常的清晰，但是這種單條sql語句在什么情況下會出現死鎖呢？我們就要去考慮這個加鎖的時機。

正常的插入邏輯是：

• 首先插入聚集索引記錄，在上例中id列為自增列。
• 隨后插入二級索引num，由于其是唯一索引，在檢查duplicate key時，為其加上類型為LOCK_X的記錄鎖。

發現錯誤：

• 由于檢測到duplicate key，因此第一步插入的聚集索引記錄需要被回滾掉（row_undo_ins）。
• 從InnoDB層失敗返回到Server層后，收到duplicate key錯誤，首先檢索唯一鍵沖突的索引，并對沖突的索引記錄（及聚集索引記錄）加鎖。

轉換模式：

如果發生uk沖突的索引是最后一個唯一索引、沒有外鍵引用、且不存在delete trigger時，使用UPDATE ROW的方式來解決沖突；
否則，使用DELETE ROW + INSERT ROW的方式解決沖突。

更新記錄：

• 對于聚集索引，由于PK列發生變化，采用delete + insert 聚集索引記錄的方式更新。
• 對于二級uk索引，同樣采用標記刪除 + 插入的方式。

所以死鎖的問題多半就會出現在X記錄鎖上面。

死鎖分析：

所以再多線程高并發的環境狀態下，存在兩個事務同時去獲取一個記錄的修改的情況：

• 事務1拿到X記錄鎖，
• 事務2檢測到沖突，獲取X|NK鎖，被事務1阻塞
• 事務1檢測到沖突，申請獲取S|NK，被事務2阻塞

所以在等待執行期間sql會有死鎖報錯，高并發環境下的死鎖也就出現了，再事務執行完成回滾操作以后，死鎖回滾，也就解釋了死鎖消失的問題。

3.解決方案：

經過多方討論，最終決定使用 insetr + ON DUPLICATE KEY UPDATE語句替換高并發環境下的Replace Into語句解決死鎖問題。

ON DUPLICATE KEY UPDATE語句的作用是：

若該數據的主鍵值/ UNIQUE KEY 已經在表中存在,則執行更新操作, 即UPDATE 后面的操作。

否則插入一條新的記錄。

實現了Replace Into有相同的查重替換功能，而避免了高并發的死鎖問題。

但是UPDATE操作性能相比DELETE操作會有一定的性能上的影響，需要后續測試跟進。

到此這篇關于高并發狀態下Replace Into造成的死鎖問題解決的文章就介紹到這了,更多相關Replace Into死鎖內容請搜索以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持！