找出未提交的MySQL線程/事務(wù)

找出未提交的MySQL線程/事務(wù):

SELECT * from information_schema.processlist;   這個(gè)能看到上面哪個(gè)SQL線程ID（下圖的378號(hào)線程就是造成MDL鎖的罪魁禍?zhǔn)祝?/span>

SELECT trx_id,trx_state,trx_started,trx_mysql_thread_id,CURRENT_TIMESTAMP - trx_started AS RUN_TIME from information_schema.innodb_trx;

然后 kill 掉378 線程即可。

補(bǔ)充：

場(chǎng)景三：

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

官方手冊(cè)上對(duì)此的說(shuō)明如下：

If the server acquires metadata locks for a statement that is syntactically valid but fails during execution, it does not release the locks early. Lock release is still deferred to the end of the transaction because the failed statement is written to the binary log and the locks protect log consistency.

也就是說(shuō)除了語(yǔ)法錯(cuò)誤，其他錯(cuò)誤語(yǔ)句獲取到的鎖在這個(gè)事務(wù)提交或回滾之前，仍然不會(huì)釋放掉。because the failed statement is written to the binary log and the locks protect log consistency 但是解釋這一行為的原因很難理解，因?yàn)殄e(cuò)誤的語(yǔ)句根本不會(huì)被記錄到二進(jìn)制日志。

處理方法：通過(guò)performance_schema.events_statements_current找到其sid, kill 掉該session. 也可以 kill 掉DDL所在的session.