如何找出长时间未提交的事务session ID

本文介绍了一种MySQL数据库中更新操作出现长时间阻塞的问题及解决方案。通过对系统状态的检查和SQL查询,定位到了一个未提交的事务导致了锁的长期占用,最终通过终止该会话解决了阻塞问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

收到报警某台mysql数据库慢查询数量超过5,登录上去看,发现阻塞的SQL全部是update,处于Updating状态

+---------+------+-----------+------+---------+------+----------+------------------------------------+
| ID      | USER | HOST      | DB   | COMMAND | TIME | STATE    | INFO                               |
+---------+------+-----------+------+---------+------+----------+------------------------------------+
| 4364109 | root | localhost | test | Query   |   39 | Updating | update T_1 set col3='' where FID=3 |
+---------+------+-----------+------+---------+------+----------+------------------------------------+

查看系统状态,各项都正常,但在InnoDB Row Lock Time值上有个较大的毛刺,基本得出是锁等待导致的。show processlist看到的线程里面,活动状态的没有发现执行慢的SQL,都是通过主键update,极有可能是某个事务对这个表做了dml操作没有提交commit,导致一直持有锁未释放,后面的session等待X锁。根据这个思路,在show engine innodb status的事务栏里面找到ACTIVE状态的,执行时间最长的那个session,发现是sleep状态的,kill掉这个session,阻塞现象消失。

---TRANSACTION 21427F91, ACTIVE 1421 sec, process no 69177, OS thread id 139633152562944
2 lock struct(s), heap size 376, 1 row lock(s), undo log entries 1
MySQL thread id 4364618, query id 282683146 localhost root

至于为什么会出现未提交SQL,再和开发一起去排查

通过show engine innodb status去查session比较麻烦,简单的SQL如下

mysql> select a.trx_mysql_thread_id,b.TIME from information_schema.INNODB_TRX a inner join information_schema.processlist b on a.trx_mysql_thread_id=b.id where a.trx_state='RUNNING' and b.time>10 and b.COMMAND='Sleep';
+---------------------+------+
| trx_mysql_thread_id | TIME |
+---------------------+------+
|             4364618 |  614 |
+---------------------+------+
1 row in set (0.00 sec)

事务ID=4364618,事务时长:614秒。

 

转载于:https://www.cnblogs.com/zuoxingyu/p/6382585.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值