背景

在程序員的職業(yè)生涯中，總會(huì)遇到數(shù)據(jù)庫表被鎖的情況，前些天就又撞見一次。由于業(yè)務(wù)突發(fā)需求，各個(gè)部門都在批量操作、導(dǎo)出數(shù)據(jù)，而數(shù)據(jù)庫又未做讀寫分離，結(jié)果就是：數(shù)據(jù)庫的某張表被鎖了!

用戶反饋系統(tǒng)部分功能無法使用，緊急排查，定位是數(shù)據(jù)庫表被鎖，然后進(jìn)行緊急處理。這篇文章給大家講講遇到類似緊急狀況的排查及解決過程，建議點(diǎn)贊收藏，以備不時(shí)之需。

故障追蹤用戶反饋某功能頁面報(bào)502錯(cuò)誤，于是第一時(shí)間看服務(wù)是否正常，數(shù)據(jù)庫是否正常。在控制臺看到數(shù)據(jù)庫CPU飆升，堆積大量未提交事務(wù)，部分事務(wù)已經(jīng)阻塞了很長時(shí)間，基本定位是數(shù)據(jù)庫層出現(xiàn)問題了。

查看阻塞事務(wù)列表，發(fā)現(xiàn)其中有鎖表現(xiàn)象，本想利用控制臺直接結(jié)束掉阻塞的事務(wù)，但控制臺賬號權(quán)限有限，于是通過客戶端登錄對應(yīng)賬號將鎖表事務(wù)kill掉，才避免了情況惡化。

下面就聊聊，如果當(dāng)突然面對類似的情況，我們該如何緊急響應(yīng)?

解決方案

想象一個(gè)場景，當(dāng)然也是軟件工程師職業(yè)生涯中會(huì)遇到的一種場景：原本運(yùn)行正常的程序，某一天突然數(shù)據(jù)庫的表被鎖了，業(yè)務(wù)無法正常運(yùn)轉(zhuǎn)，那么我們該如何快速定位是哪個(gè)事務(wù)鎖了表，如何結(jié)束對應(yīng)的事物?

首先最簡單粗暴的方式就是：重啟MySQL。對的，網(wǎng)管解決問題的神器——“重啟”。至于后果如何，你能不能跑了，要你自己三思而后行了!

重啟是可以解決表被鎖的問題的，但針對線上業(yè)務(wù)很顯然不太具有可行性。

下面來看看不用跑路的解決方案：

第一步：查看表使用

遇到數(shù)據(jù)庫阻塞問題，首先要查詢一下表是否在使用。

show open tables where in_use > 0 ;

如果查詢結(jié)果為空，那么說明表沒在使用，說明不是鎖表的問題。

mysql>  show open tables where in_use > 0 ;
Empty set (0.00 sec)

如果查詢結(jié)果不為空，比如出現(xiàn)如下結(jié)果：

mysql>  show open tables where in_use > 0 ;
+----------+-------+--------+-------------+
| Database | Table | In_use | Name_locked |
+----------+-------+--------+-------------+
| test     | t     |      1 |           0 |
+----------+-------+--------+-------------+
1 row in set (0.00 sec)

則說明表(test)正在被使用，此時(shí)需要進(jìn)一步排查。

第二步：查看進(jìn)程

查看數(shù)據(jù)庫當(dāng)前的進(jìn)程，看看是否有慢SQL或被阻塞的線程。

執(zhí)行命令：

show processlist;

該命令只顯示當(dāng)前用戶正在運(yùn)行的線程，當(dāng)然，如果是root用戶是能看到所有的。

在上述實(shí)踐中，阿里云控制臺之所以能夠查看到所有的線程，猜測應(yīng)該使用的就是root用戶，而筆者去kill的時(shí)候，無法kill掉，是因?yàn)榈卿浀挠脩舴莚oot的數(shù)據(jù)庫賬號，無法操作另外一個(gè)用戶的線程。

第三步：查看當(dāng)前運(yùn)行的所有事務(wù)

如果情況緊急，此步驟可以跳過，主要用來查看核對：

SELECT * FROM information_schema.INNODB_TRX;

第四步：查看當(dāng)前出現(xiàn)的鎖

如果情況緊急，此步驟可以跳過，主要用來查看核對：

SELECT * FROM information_schema.INNODB_LOCKs;

第五步：查詢鎖等待的對應(yīng)關(guān)系

SELECT * FROM information_schema.INNODB_LOCK_waits;

看事務(wù)表INNODB_TRX中是否有正在鎖定的事務(wù)線程，看看ID是否在show processlist的sleep線程中。如果在，說明這個(gè)sleep的線程事務(wù)一直沒有commit或者rollback，而是卡住了，需要手動(dòng)kill掉。

搜索的結(jié)果中，如果在事務(wù)表發(fā)現(xiàn)了很多任務(wù)，最好都kill掉。

第六步：kill掉事務(wù)

執(zhí)行kill命令：

kill 1011;

對應(yīng)的線程都執(zhí)行完kill命令之后，后續(xù)事務(wù)便可正常處理。

針對緊急情況，通常也會(huì)直接操作第一、第二、第六步。

MySQL的鎖

這里再補(bǔ)充一些MySQL鎖相關(guān)的知識點(diǎn)：數(shù)據(jù)庫鎖設(shè)計(jì)的初衷是處理并發(fā)問題，作為多用戶共享的資源，當(dāng)出現(xiàn)并發(fā)訪問的時(shí)候，數(shù)據(jù)庫需要合理地控制資源的訪問規(guī)則，而鎖就是用來實(shí)現(xiàn)這些訪問規(guī)則的重要數(shù)據(jù)結(jié)構(gòu)。

根據(jù)加鎖的范圍，MySQL里面的鎖大致可以分成全局鎖、表級鎖和行鎖三類。MySQL中表級別的鎖有兩種：一種是表鎖，一種是元數(shù)據(jù)鎖(metadata lock，MDL)。

表鎖是在Server層實(shí)現(xiàn)的，ALTER TABLE之類的語句會(huì)使用表鎖，忽略存儲(chǔ)引擎的鎖機(jī)制。表鎖通過lock tables... read/write來實(shí)現(xiàn)，而對于InnoDB來說，一般會(huì)采用行級鎖。畢竟鎖住整張表影響范圍太大了。

另外一個(gè)表級鎖是MDL(metadata lock)，用于并發(fā)情況下維護(hù)數(shù)據(jù)的一致性，保證讀寫的正確性，不需要顯式的使用，在訪問一張表時(shí)會(huì)被自動(dòng)加上。

MySQL鎖表場景

常見的一種鎖表場景就是有事務(wù)操作處于：Waiting for table metadata lock狀態(tài)。

Waiting for table metadata lock

MySQL在進(jìn)行alter table等DDL操作時(shí)，有時(shí)會(huì)出現(xiàn)Waiting for table metadata lock的等待場景。

一旦alter table TableA的操作停滯在Waiting for table metadata lock狀態(tài)，后續(xù)對該表的任何操作(包括讀)都無法進(jìn)行，因?yàn)樗鼈円矔?huì)在Opening tables的階段進(jìn)入到Waiting for table metadata lock的鎖等待隊(duì)列。如果核心表出現(xiàn)了鎖等待隊(duì)列，就會(huì)造成災(zāi)難性的后果。

場景一：長事務(wù)運(yùn)行，阻塞DDL，繼而阻塞所有同表的后續(xù)操作。

通過show processlist可以看到表上有正在進(jìn)行的操作(包括讀)，此時(shí)alter table語句無法獲取到metadata 獨(dú)占鎖，會(huì)進(jìn)行等待。

場景二：為提交事務(wù)，阻塞DDL，繼而阻塞所有同表的后續(xù)操作。

通過show processlist看不到表上有任何操作，但實(shí)際上存在有未提交的事務(wù)，可以在information_schema.innodb_trx中查看到。在事務(wù)沒有完成之前，表上的鎖不會(huì)釋放，alter table同樣獲取不到metadata的獨(dú)占鎖。

處理方法：通過 select * from information_schema.innodb_trx\G, 找到未提交事物的sid，然后kill掉，讓其回滾。

場景三：顯式事務(wù)失敗操作獲得鎖，未釋放

通過show processlist看不到表上有任何操作，在information_schema.innodb_trx中也沒有任何進(jìn)行中的事務(wù)。很可能是因?yàn)樵谝粋€(gè)顯式的事務(wù)中，對表進(jìn)行了一個(gè)失敗的操作(比如查詢了一個(gè)不存在的字段)，這時(shí)事務(wù)沒有開始，但是失敗語句獲取到的鎖依然有效，沒有釋放。從performance_schema.events_statements_current表中可以查到失敗的語句。

處理方法：通過performance_schema.events_statements_current找到其sid，kill 掉該session，也可以kill掉DDL所在的session。

總之，alter table的語句是很危險(xiǎn)的(核心是未提交事務(wù)或者長事務(wù)導(dǎo)致的)，在操作之前要確認(rèn)對要操作的表沒有任何進(jìn)行中的操作、沒有未提交事務(wù)、也沒有顯式事務(wù)中的報(bào)錯(cuò)語句。

如果有alter table的維護(hù)任務(wù)，在無人監(jiān)管的時(shí)候運(yùn)行，最好通過lock_wait_timeout設(shè)置好超時(shí)時(shí)間，避免長時(shí)間的metedata鎖等待。

小結(jié)

關(guān)于MySQL的鎖表其實(shí)還有很多其他場景，我們在實(shí)踐的過程中盡量避免鎖表情況的發(fā)生，當(dāng)然這需要一定經(jīng)驗(yàn)的支撐。但更重要的是，如果發(fā)現(xiàn)鎖表我們要能夠快速的響應(yīng)，快速的解決問題，避免影響正常業(yè)務(wù)，避免情況進(jìn)一步惡化。所以，本文中的解決思路大家一定要收藏或記憶一下，做到有備無患，避免突然狀況下抓瞎。