前言

數(shù)據(jù)庫死鎖問題是我們老生常談的問題了，在我們實(shí)際開發(fā)過程中經(jīng)常會(huì)遇到，為了盡量避免出現(xiàn)死鎖，我們需要了解出現(xiàn)死鎖的場景。同時(shí)，如果線上出現(xiàn)了死鎖之后怎么去分析、排查和解決，下面我就這兩點(diǎn)介紹一下。

一、數(shù)據(jù)庫死鎖介紹

1、什么是數(shù)據(jù)庫死鎖？

數(shù)據(jù)庫的死鎖是指：不同的事務(wù)在獲取資源時(shí)相互等待，導(dǎo)致無法繼續(xù)執(zhí)行的一種情況。當(dāng)發(fā)生死鎖時(shí)，數(shù)據(jù)庫系統(tǒng)會(huì)自動(dòng)中斷其中一個(gè)事務(wù)，以解除死鎖。在數(shù)據(jù)庫中，事務(wù)可以分為讀事務(wù)和寫事務(wù)。讀事務(wù)只需要獲取讀鎖，而寫事務(wù)需要獲取寫鎖。當(dāng)多個(gè)事務(wù)同時(shí)操作同一組數(shù)據(jù)時(shí)，可能會(huì)引發(fā)死鎖的出現(xiàn)。

2、MySQL 發(fā)生死鎖的場景

2-1、事務(wù)同時(shí)更新多個(gè)表

當(dāng)一個(gè)事務(wù)同時(shí)更新多個(gè)表并且使用了不同的順序，可能會(huì)導(dǎo)致死鎖的發(fā)生。例如，事務(wù) A 首先更新表 X，此時(shí)獲取到了 X 表的鎖，并在未釋放該鎖的情況下嘗試更新表 Y；而事務(wù) B 首先更新表Y，此時(shí)獲取到了 Y 表的鎖，并在未釋放鎖的情況下嘗試更新表 X。這種情況下，兩個(gè)事務(wù)會(huì)相互等待對(duì)方的鎖釋放，從而形成死鎖。

2-2、事務(wù)嵌套

當(dāng)一個(gè)事務(wù)內(nèi)部開啟了另一個(gè)事務(wù)，并在內(nèi)層事務(wù)中更新了某個(gè)表，而外層事務(wù)也需要更新該表的同一行記錄時(shí)，就有可能發(fā)生死鎖。因?yàn)橥鈱邮聞?wù)需要等待內(nèi)層事務(wù)釋放鎖，而內(nèi)層事務(wù)需要等待外層事務(wù)釋放鎖。

2-3、索引順序不一致

當(dāng)多個(gè)事務(wù)按照不同的順序訪問相同的數(shù)據(jù)行，并且使用了不同的索引時(shí)，可能會(huì)發(fā)生死鎖。例如，事務(wù) A 按照索引 1 的順序訪問數(shù)據(jù)行，事務(wù) B 按照索引 2 的順序訪問同一組數(shù)據(jù)行，這樣兩個(gè)事務(wù)之間就會(huì)產(chǎn)生死鎖。

2-4、不同事務(wù)同時(shí)更新相同的索引

當(dāng)多個(gè)事務(wù)同時(shí)更新相同的索引時(shí)，可能會(huì)導(dǎo)致死鎖。這是因?yàn)槭聞?wù)在更新索引時(shí)會(huì)獲取對(duì)應(yīng)的鎖，并在未釋放鎖的情況下嘗試更新其他數(shù)據(jù)，從而形成死鎖。

二、解決死鎖問題

如果線上發(fā)生了死鎖，我們應(yīng)該采取以下步驟進(jìn)行處理：

1、 監(jiān)控死鎖

正常情況下我們都會(huì)建立死鎖監(jiān)控機(jī)制，以便及時(shí)掌握死鎖情況；同時(shí)設(shè)置相應(yīng)的預(yù)警機(jī)制，以便在死鎖發(fā)生時(shí)能夠及時(shí)處理。

通過數(shù)據(jù)庫的監(jiān)控工具或命令可以查看是否存在死鎖情況，如果出現(xiàn)則了解死鎖的具體情況，包括死鎖的事務(wù)和死鎖的資源。

2、終止死鎖事務(wù)

根據(jù)監(jiān)控結(jié)果，找到造成死鎖的事務(wù)，并手動(dòng)選擇其中一個(gè)事務(wù)終止。可以根據(jù)事務(wù)的執(zhí)行時(shí)間、影響行數(shù)、優(yōu)先級(jí)等因素進(jìn)行終止決策?？梢酝ㄟ^ select * from information_schema.innodb_trx 語句查看死鎖情況。

在 innodb 中，有三張表可以幫助我們更好去分析死鎖信息：

• information_schema.innodb_trx：事務(wù)信息表。
• information_schema.innodb_locks：事務(wù)鎖的信息表。
• information_schema.innodb_lock_waits：鎖等待關(guān)系表。

系統(tǒng)自動(dòng)解除死鎖：

正常情況下，當(dāng)發(fā)生死鎖時(shí)，MySQL 系統(tǒng)會(huì)自動(dòng)解除死鎖，至于解除哪個(gè)事務(wù)的鎖，需要虧了一個(gè)代價(jià)，在解除死鎖方面，會(huì)選擇回滾事務(wù)產(chǎn)生影響最小的一個(gè)進(jìn)行回滾。

這里就要提一下兩個(gè)概念了，一個(gè)是事務(wù)的權(quán)重（trx_weight），另外一個(gè)是事務(wù)的調(diào)度權(quán)重（trx_schedule_weight）：

• 事務(wù)的權(quán)重：與回滾事務(wù)的選擇有關(guān)。具體與事務(wù) undo 版本鏈的長度有關(guān)，回滾的 undo 記錄越多，產(chǎn)生的影響就會(huì)越大，MySQL 就不會(huì)選擇這樣的事務(wù)，倘若事務(wù)權(quán)重一樣，會(huì)選擇事務(wù)等待隊(duì)列等待時(shí)間短的事務(wù)進(jìn)行回滾。
• 事務(wù)的調(diào)度權(quán)重：與事務(wù)獲取資源的先后有關(guān)。MySQL8.0.20 之前在等待鎖的事務(wù)優(yōu)先級(jí)排序采取 FIFO 算法，之后采取 CATS 算法。該算法通過分配調(diào)度權(quán)限對(duì)等待的事務(wù)進(jìn)行優(yōu)先級(jí)排序，該權(quán)重是根據(jù)事務(wù)阻塞的事務(wù)數(shù)量計(jì)算的。例如，兩個(gè)事務(wù)正在等待同一對(duì)象上的鎖，那么阻塞最多事務(wù)的事務(wù)將被分配更大的調(diào)度權(quán)重，如果權(quán)重相等，則優(yōu)先考慮等待時(shí)間最長的事務(wù)分配資源。

3、重試事務(wù)

終止死鎖事務(wù)后，需要重新執(zhí)行被終止的事務(wù)。這可能需要一些邏輯處理，例如對(duì)數(shù)據(jù)進(jìn)行回滾或者重新執(zhí)行一些操作。

4、分析死鎖原因

通過數(shù)據(jù)庫的日志和監(jiān)控信息，分析死鎖的原因。下面是查看死鎖日志的命令語句：

show engine innodb status;

分析死鎖日志然后根據(jù)死鎖原因?qū)?shù)據(jù)庫的設(shè)計(jì)和代碼進(jìn)行優(yōu)化，以盡量減少死鎖的發(fā)生。

同時(shí)也可以根據(jù)分析結(jié)果，針對(duì)性地進(jìn)行數(shù)據(jù)庫結(jié)構(gòu)調(diào)整、索引優(yōu)化、事務(wù)隔離級(jí)別調(diào)整等措施，以降低死鎖的概率。

5、避免死鎖建議

• 事務(wù)盡可能小，不要將復(fù)雜邏輯放進(jìn)一個(gè)事務(wù)里。
• 涉及多行記錄時(shí)，約定不同事務(wù)以相同順序訪問。
• 業(yè)務(wù)中要及時(shí)提交或者回滾事務(wù)，可減少死鎖產(chǎn)生的概率。
• 表要有合適的索引。
• 可嘗試將隔離級(jí)別改為 ReadCommit 。

 到此這篇關(guān)于MySQL之死鎖問題及其解決方案的文章就介紹到這了,更多相關(guān)MySQL 死鎖內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論