mysql中两表更新时产生的奇葩问题，产生死锁！

最新推荐文章于 2024-08-16 21:28:19 发布

转载最新推荐文章于 2024-08-16 21:28:19 发布 · 513 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：http://www.cnblogs.com/wxb-km/p/5999852.html

文章标签：

#数据库

本文通过一个具体的SQL更新语句实例，阐述了WHERE子句在避免全表扫描和防止数据库死锁中的关键作用。若省略WHERE条件，不仅会导致不必要的资源消耗，还可能引发长时间的表锁定，严重影响应用系统的正常运行。

如下一个两表更新语句

UPDATE hzxm201610 a,xmhzylb1201610 b SET a.gk07_1_6=b.gk04_11,a.gk07_2_6=b.f06_1,a.gk07_3_6=b.f07_1,a.gk07_4_6=b.f08_1 where substring(a.gk01,1,4) in ('5323') and a.gk01=b.gk01 and dqdm='532300'

如果漏掉了where会怎么样：

UPDATE hzxm201610 a,xmhzylb1201610 b SET a.gk07_1_6=b.gk04_11,a.gk07_2_6=b.f06_1,a.gk07_3_6=b.f07_1,a.gk07_4_6=b.f08_1 substring(a.gk01,1,4) in ('5323') and a.gk01=b.gk01 and dqdm='532300'

一般以为是会报错。其实不然，这个语句正常执行！而且对两个表全扫描，最后什么也不做！但是会锁定两个表很长时间，导致应用系统无法工作！

查询mysql死锁的语句：

#Show PROCESSLIST;
SELECT * FROM information_schema.INNODB_TRX;
SELECT * FROM information_schema.INNODB_LOCKS;
SELECT * FROM information_schema.INNODB_LOCK_WAITS;
SHOW VARIABLES LIKE '%lock%';

转载于:https://www.cnblogs.com/wxb-km/p/5999852.html