怎么解決Mysql Sleep線(xiàn)程引發(fā)的鎖等待故障

本篇內容主要講解“怎么解決 Sleep線(xiàn)程引發(fā)的鎖等待故障”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強。下面就讓小編來(lái)帶大家學(xué)習“怎么解決Mysql Sleep線(xiàn)程引發(fā)的鎖等待故障”吧!

背景：

負責的生產(chǎn)庫出現告警too many connections.

解決過(guò)程：

1. 第一反應就是出現了大量的連接或者是DDL把實(shí)例打滿(mǎn)了，隨即登上實(shí)例嘗試登陸，卻發(fā)現已經(jīng)連不上了。然后動(dòng)態(tài)調大連接數后。使用如下SQL看到大量的UPDATE線(xiàn)程未執行完。

select id,host,user,db,command,state,time,left(info,200) from information_schema.processlist where command <>'Sleep' order by time desc limit 100;

2. 此時(shí)看到這個(gè)場(chǎng)景，大家大概率都會(huì )以為是表tbl_prod的ID沒(méi)有索引所以是全表查找更新，然而看到執行計劃卻發(fā)現并不是，反而是主鍵更新。

explain UPDATE tbl_prod SET status=1 WHERE id = 1198445;

3. 隨后查看innodb引擎當前的狀態(tài),發(fā)現很有意思的事了，這些update線(xiàn)程都在等待鎖，以其中一個(gè)線(xiàn)程為例。

show engine innodb status\G

4. 此時(shí)基本上可以斷定是有長(cháng)事務(wù)未提交導致的大量主鍵更新等待了。我們采用如下SQL可以找到這個(gè)長(cháng)連接。

select p.host,p.time,t.trx_mysql_thread_id,t.trx_started,left(p.info,100) from information_schema.innodb_trx t join information_schema.processlist p  on t.trx_mysql_thread_id =p.id order by time desc,t.trx_started desc limit 20;

5. 可以看到上面的第一條執行時(shí)間最長(cháng)的為NULL的線(xiàn)程占用鎖時(shí)間最長(cháng)，其后則是大量的update等待線(xiàn)程了。那么我們將這個(gè)最長(cháng)的null線(xiàn)程給KILL掉，問(wèn)題即得到解決。

kill 2323514;