Java自学者论坛

 找回密码
 立即注册

手机号码,快捷登录

恭喜Java自学者论坛(https://www.javazxz.com)已经为数万Java学习者服务超过8年了!积累会员资料超过10000G+
成为本站VIP会员,下载本站10000G+会员资源,会员资料板块,购买链接:点击进入购买VIP会员

JAVA高级面试进阶训练营视频教程

Java架构师系统进阶VIP课程

分布式高可用全栈开发微服务教程Go语言视频零基础入门到精通Java架构师3期(课件+源码)
Java开发全终端实战租房项目视频教程SpringBoot2.X入门到高级使用教程大数据培训第六期全套视频教程深度学习(CNN RNN GAN)算法原理Java亿级流量电商系统视频教程
互联网架构师视频教程年薪50万Spark2.0从入门到精通年薪50万!人工智能学习路线教程年薪50万大数据入门到精通学习路线年薪50万机器学习入门到精通教程
仿小米商城类app和小程序视频教程深度学习数据分析基础到实战最新黑马javaEE2.1就业课程从 0到JVM实战高手教程MySQL入门到精通教程
查看: 550|回复: 0

一次MySQL死锁问题解决

[复制链接]
  • TA的每日心情
    奋斗
    2024-4-6 11:05
  • 签到天数: 748 天

    [LV.9]以坛为家II

    2034

    主题

    2092

    帖子

    70万

    积分

    管理员

    Rank: 9Rank: 9Rank: 9

    积分
    705612
    发表于 2021-8-30 15:26:13 | 显示全部楼层 |阅读模式

    一次MySQL死锁问题解决

    一、环境

    • CentOS, MySQL 5.6.21-70, JPA
    • 问题场景:系统有定时批量更新数据状态操作,每次更新上千条记录,表中总记录数约为500W左右。

    二、错误日志

    
    2017-2-25 17:38:41 org.hibernate.util.JDBCExceptionReporter logExceptions
    严重: Lock wait timeout exceeded; try restarting transaction
    2017-2-25 17:39:05 org.hibernate.util.JDBCExceptionReporter logExceptions
    警告: SQL Error: 1213, SQLState: 40001
    2017-2-25 17:39:05 org.hibernate.util.JDBCExceptionReporter logExceptions
    严重: Deadlock found when trying to get lock; try restarting transaction
    
    

    三、排查

    Check InnoDB status for locks
    mysql> SHOW ENGINE InnoDB STATUS;
    
    Check MySQL open tables
    mysql> SHOW OPEN TABLES WHERE In_use > 0;
    
    Check pending InnoDB transactions
    mysql> SELECT * FROM `information_schema`.`innodb_trx` ORDER BY `trx_started`; 
    
    Check lock dependency - what blocks what
    mysql> SELECT * FROM `information_schema`.`innodb_locks`;
    

    排查后发现都是执行类似这样的语句出现问题的:

    
    update t_task_tel set state='iok', update_date='2017-02-27 11:03:02' where tel_id=66042 and task_id=350199;
    
    

    四、分析

    搜索相关资料后发现,原来MySQL InnoDB并不一定都是行级锁。

    相关参考资料片段如下:

    MySQL InnoDB锁机制之Gap Lock、Next-Key Lock、Record Lock解析
    http://blog.sina.com.cn/s/blog_a1e9c7910102vnrj.html
    
    4、锁选择
    1)、如果更新条件没有走索引,例如执行”update from t1 set v2=0 where v2=5;” ,此时会进行全表扫描,扫表的时候,要阻止其他任何的更新操作,所以上升为表锁。
    2)、如果更新条件为索引字段,但是并非唯一索引(包括主键索引),例如执行“update from t1 set v2=0 where v1=9;” 那么此时更新会使用Next-Key Lock。使用Next-Key Lock的原因:
    a)、首先要保证在符合条件的记录上加上排他锁,会锁定当前非唯一索引和对应的主键索引的值;
    b)、还要保证锁定的区间不能插入新的数据。
    3)、如果更新条件为唯一索引,则使用Record Lock(记录锁)。
     
    InnoDB根据唯一索引,找到相应记录,将主键索引值和唯一索引值加上记录锁。但不使用Gap Lock(间隙锁)。
    
    MySQL InnoDB 锁表与锁行
    http://blog.csdn.net/qq250782929/article/details/52063975
    
    由于InnoDB预设是Row-Level Lock,所以只有「明确」的指定主键,MySQL才会执行Row lock (只锁住被选取的资料例) ,否则MySQL将会执行Table Lock (将整个资料表单给锁住)。
    
    

    根据分析结论,猜测是在更新_task_tel表时Where条件中tel_id和task_id没有建立UNIQUE(唯一索引)原因;

    五、解决

    据此分析,尝试通过tel_id和task_id两个字段建立UNIQUE(唯一索引)来解决。 (也可以先查询出来,然后根据主键ID来更新,这样不会因表中数据量较大影响线上业务)。

    用索引字段做为条件进行修改时, 是否表锁的取决于这个索引字段能否确定记录唯一,当索引值对应记录不唯一,会进行锁表,相反则行锁。

    通过此种方式解决后,问题没有再重现。

    如果你的问题和我遇到的类似,可以尝试据此解决。

    六、参考资料

    哎...今天够累的,签到来了1...
    回复

    使用道具 举报

    您需要登录后才可以回帖 登录 | 立即注册

    本版积分规则

    QQ|手机版|小黑屋|Java自学者论坛 ( 声明:本站文章及资料整理自互联网,用于Java自学者交流学习使用,对资料版权不负任何法律责任,若有侵权请及时联系客服屏蔽删除 )

    GMT+8, 2024-4-30 12:52 , Processed in 0.074338 second(s), 29 queries .

    Powered by Discuz! X3.4

    Copyright © 2001-2021, Tencent Cloud.

    快速回复 返回顶部 返回列表