mysql死锁

在本地测试代码时遇到MySQL死锁问题,由于执行删除语句时中断程序导致。文章提供了查询和解决死锁的步骤,包括通过MySQL后台检查进程,识别并杀死引起死锁的进程,以及优化SQL操作以减少锁表概率。建议减少事务执行到提交之间的时长,批量操作改为单个执行,并优化SQL性能。
摘要由CSDN通过智能技术生成

一日本地测试代码时,根据日期清空mysql表数据(分别执行两条删除语句并添加了事务),但执行第一句时时间较长,直接点击idea-tomcat-stop xxxTest退出程序,重新发起测试,执行第一句删除语句还是卡死,恩,应该死锁了,代码如下:

@Transactional
    public void clear(String date){
        ZjZBDataDao.clearZjZBData(date);
        ZjZBDataDao.clearZjZBDataRecord(date);
    }

mysql死锁解决方法:

登录mysql后台

su - mysql

/usr/local/mysql/bin/mysql -u数据库名 -p --socket=/mysql/data/mysql.sock

执行以下命令,查询mysql数据库中存在的进程

>show processlist;

>SELECT * FROM information_schema.`PROCESSLIST`;

示例:

mysql> SELECT * FROM information_schema.`PROCESSLIST` where db='snbedss'

-> ;

+---------+------+---------------------+---------+---------+------+-------+------+---------+-----------+---------------+

| ID | USER | HOST | DB | COMMAND | TIME | STATE | INFO | TIME_MS | ROWS_SENT | ROWS_EXAMINED |

+---------+------+---------------------+---------+---------+------+-------+------+---------+-----------+---------------+

| 5312676 | edss | yy.yy.yy.yy:57300 | snbedss | Sleep | 3189 | | NULL | 3188670 | 0 | 0 |

| 5308628 | edss | xx.xx.xx.xx:32240 | snbedss | Sleep | 159 | | NULL | 159630 | 0 | 0 |

| 5317725 | clms | yy.yy.yy.yy:60264 | snbedss | Sleep | 210 | | NULL | 210058 | 16 | 330 |

| 5306522 | edss | xx.xx.xx.xx:19522 | snbedss | Sleep | 161 | | NULL | 160654 | 1 | 147 |

| 5316038 | clms | yy.yy.yy.yy:59895 | snbedss | Sleep | 510 | | NULL | 510302 | 11 | 11 |

| 5308600 | edss | xx.xx.xx.xx:52241 | snbedss | Sleep | 6422 | | NULL | 6422118 | 1 | 0 |

| 5316039 | clms | yy.yy.yy.yy:59898 | snbedss | Sleep | 1526 | | NULL | 1525711 | 0 | 0 |

| 5308601 | edss | xx.xx.xx.xx:52242 | snbedss | Sleep | 6419 | | NULL | 6419583 | 4 | 8 |

| 5314763 | clms | yy.yy.yy.yy:59101 | snbedss | Sleep | 2337 | | NULL | 2337003 | 24 | 24 |

| 5318149 | clms | yy.yy.yy.yy:60294 | snbedss | Sleep | 246 | | NULL | 245740 | 16 | 137 |

| 5308619 | edss | xx.xx.xx.xx:32215 | snbedss | Sleep | 159 | | NULL | 159504 | 0 | 1 |

| 5308620 | edss | xx.xx.xx.xx:32216 | snbedss | Sleep | 159 | | NULL | 159627 | 1 | 147 |

| 5302357 | edss | xx.xx.xx.xx:59235 | snbedss | Sleep | 161 | | NULL | 160652 | 0 | 1 |

| 5305169 | edss | xx.xx.xx.xx:29621 | snbedss | Sleep | 159 | | NULL | 159508 | 0 | 0 |

| 5316457 | clms | yy.yy.yy.yy:60052 | snbedss | Sleep | 154 | | NULL | 153663 | 16 | 330 |

+---------+------+---------------------+---------+---------+------+-------+------+---------+-----------+---------------+

yy.yy.yy.yy为自己本机ip,找到进程id

杀掉进程

kill 5312676/5317725/5316038/5316039..............

再次发起测试,问题解决

拓展:摘自(https://www.cnblogs.com/czbnuli/p/16555498.html)

锁表的原因:

1、锁表发生在insert 、update 、delete 中;

2、锁表的原理是 数据库使用独占式封锁机制,当执行上面的语句时,对表进行锁住,直到发生commite 或者 回滚 或者退出数据库用户;

3、锁表的原因 :

1)、A程序执行了对 tableA 的 insert ,并还未 commite时,B程序也对tableA 进行insert 则此时会发生资源正忙的异常 就是锁表;

2)、锁表常发生于并发而不是并行(并行时,一个线程操作数据库时,另一个线程是不能操作数据库的,cpu 和i/o 分配原则)

4、减少锁表的概率:

减少insert 、update 、delete 语句执行 到 commite 之间的时间。

具体点批量执行改为单个执行、优化sql自身的非执行速度

如果异常对事物进行回滚。

相关命令:

--查询正在执行的事务:

SELECT * FROM information_schema.INNODB_TRX;

-- 查看正在锁的事务

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;

-- 查看等待锁的事务

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;

-- 查询mysql数据库中存在的进程

select * from information_schema.`PROCESSLIST`(show processlist;)

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值