解決線上數(shù)據(jù)庫死鎖，就是這么簡單！

前幾天，線上發(fā)生了一次數(shù)據(jù)庫死鎖問題，這一問題前前后后排查了比較久的時間，這個過程中自己也對數(shù)據(jù)庫的鎖機制有了更深的理解。

updateFundStreamId 執(zhí)行的時候使用到的是 PRIMARY 索引。

updateStatus 執(zhí)行的時候使用到的是 idx_seller_transNo 索引。

通過執(zhí)行計劃，我們發(fā)現(xiàn) updateStatus 其實是有兩個索引可以用的，執(zhí)行的時候真正使用的是 idx_seller_transNo 索引。這是因為 MySQL 查詢優(yōu)化器是基于代價(cost-based)的查詢方式。

因此，在查詢過程中，最重要的一部分是根據(jù)查詢的 SQL 語句，依據(jù)多種索引，計算查詢需要的代價，從而選擇最優(yōu)的索引方式生成查詢計劃。

我們查詢執(zhí)行計劃是在死鎖發(fā)生之后做的，事后查詢的執(zhí)行計劃和發(fā)生死鎖那一刻的索引使用情況并不一定是相同的。

但是，我們結(jié)合死鎖日志，也可以定位到以上兩條 SQL 語句執(zhí)行的時候使用到的索引。

即 updateFundStreamId 執(zhí)行的時候使用到的是 PRIMARY 索引，updateStatus 執(zhí)行的時候使用到的是 idx_seller_transNo 索引。

有了以上這些已知信息，我們就可以開始排查死鎖原因及其背后的原理了。

通過分析死鎖日志，再結(jié)合我們的代碼以及數(shù)據(jù)庫建表語句，我們發(fā)現(xiàn)主要問題出在我們的 idx_seller_transNo 索引上面：

KEY `idx_seller_transNo` (`seller_id`,`fund_transfer_order_no`(20)) 

索引創(chuàng)建語句中，我們使用了前綴索引，為了節(jié)約索引

那么為什么 fund_transfer_order_no 的前 20 位相同會導(dǎo)致死鎖呢?

加鎖原理

我們就拿本次的案例來看一下 MySQL 數(shù)據(jù)庫加鎖的原理是怎樣的，本文的死鎖背后又發(fā)生了什么。

我們在數(shù)據(jù)庫上模擬死鎖場景，執(zhí)行順序如下：

我們知道，在 MySQL 中，行級鎖并不是直接鎖記錄，而是鎖索引。索引分為主鍵索引和非主鍵索引兩種：

• 如果一條 SQL 語句操作了主鍵索引，MySQL 就會鎖定這條主鍵索引。
• 如果一條語句操作了非主鍵索引，MySQL 會先鎖定該非主鍵索引，再鎖定相關(guān)的主鍵索引。

主鍵索引的葉子節(jié)點存的是整行數(shù)據(jù)。在 InnoDB 中，主鍵索引也被稱為聚簇索引(Clustered Index)。

非主鍵索引的葉子節(jié)點的內(nèi)容是主鍵的值，在 InnoDB 中，非主鍵索引也被稱為非聚簇索引(Secondary Index)。

所以，本文的示例中涉及到的索引結(jié)構(gòu)(索引是 B+ 樹，簡化成表格了)如圖：

死鎖的發(fā)生與否，并不在于事務(wù)中有多少條 SQL 語句，死鎖的關(guān)鍵在于：兩個(或以上)的 Session 加鎖的順序不一致。

當(dāng)前標(biāo)題：解決線上數(shù)據(jù)庫死鎖，就是這么簡單！
鏈接分享：http://www.bm7419.com/news29/103129.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)網(wǎng)站建設(shè)、品牌網(wǎng)站制作、營銷型網(wǎng)站建設(shè)、網(wǎng)站內(nèi)鏈、網(wǎng)站導(dǎo)航、網(wǎng)站營銷

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)