MySQL相关 – 死锁的发生和避免

MySQL相关 – 死锁的发生和避免

大家好,又见面了,我是全栈君。

在我们使用锁的时候,有一个问题是需要注意和避免的,我们知道,排它锁有互斥的特性。一个事务或者说一个线程持有锁的时候,会阻止其他的线程获取锁,这个时候会造成阻塞等待,如果循环等待,会有可能造成死锁

这个问题我们需要从几个方面来分析,一个是锁为什么不释放,第二个是被阻塞了怎么办,第三个死锁是怎么发生的,怎么避免。我们且看正文部分。

: 在这里插入图片描述

正文

死锁

锁的释放与阻塞

回顾:锁什么时候释放?

事务结束(commit,rollback);客户端连接断开。

如果一个事务一直未释放锁,其他事务会被阻塞多久?会不会永远等待下去?如果是,在并发访问比较高的情况下,如果大量事务因无法立即获得所需的锁而挂起,会占用大量计算机资源,造成严重性能问题,甚至拖跨数据库。

[Err] 1205 – Lock wait timeout exceeded; try restarting transaction MySQL 有一个参数来控制获取锁的等待时间,默认是 50 秒。

show VARIABLES like 'innodb_lock_wait_timeout';

在这里插入图片描述

对于死锁,是无论等多久都不能获取到锁的,这种情况,也需要等待 50 秒钟吗?那

不是白白浪费了 50 秒钟的时间吗?

我们先来看一下什么时候会发生死锁。

死锁的发生和检测

死锁演示:

Session 1 Session 2
begin;<br/>select * from t2 where id =1 for update;  
begin;<br />delete from t2 where id =4 ;
update t2 set name= ‘4d’ where id =4 ;  
delete from t2 where id =1 ;

在第一个事务中,检测到了死锁,马上退出了,第二个事务获得了锁,不需要等待 50 秒:

[Err] 1213 – Deadlock found when trying to get lock; try restarting transaction

为什么可以直接检测到呢?是因为死锁的发生需要满足一定的条件,所以在发生死锁时,InnoDB 一般都能通过算法(wait-for graph)自动检测到。

那么死锁需要满足什么条件?死锁的产生条件:

因为锁本身是互斥的 (1)同一时刻只能有一个事务持有这把锁; (2)其他的事务需要在这个事务释放锁之后才能获取锁,而不可以强行剥夺; (3)当多个事务形成等待环路的时候,即发生死锁。

举例:

理发店有两个总监。一个负责剪头的 Tony 总监,一个负责洗头的 Kelvin 总监。

Tony 不能同时给两个人剪头,这个就叫互斥。

Tony 在给别人在剪头的时候,你不能让他停下来帮你剪头,这个叫不能强行剥夺。如果 Tony 的客户对 Kelvin 总监说:你不帮我洗头我怎么剪头?Kelvin 的客户对 Tony 总监说:你不帮我剪头我怎么洗头?这个就叫形成等待环路。

如果锁一直没有释放,就有可能造成大量阻塞或者发生死锁,造成系统吞吐量下降,这时候就要查看是哪些事务持有了锁。

查看锁信息(日志)

SHOW STATUS 命令中,包括了一些行锁的信息:

show status like 'innodb_row_lock_%';

在这里插入图片描述

  • Innodb_row_lock_current_waits:当前正在等待锁定的数量;
  • Innodb_row_lock_time :从系统启动到现在锁定的总时间长度,单位 ms;
  • Innodb_row_lock_time_avg :每次等待所花平均时间;
  • Innodb_row_lock_time_max:从系统启动到现在等待最长的一次所花的时间;
  • Innodb_row_lock_waits :从系统启动到现在总共等待的次数。

SHOW 命令是一个概要信息。InnoDB 还提供了三张表来分析事务与锁的情况:

select * from information_schema.INNODB_TRX;	-- 当前运行的所有事务 ,还有具体的语句

在这里插入图片描述

select * from information_schema.INNODB_LOCKS;	--  当前出现的锁

在这里插入图片描述

select * from information_schema.INNODB_LOCK_WAITS;	--  锁等待的对应关系

在这里插入图片描述

找出持有锁的事务之后呢?

如果一个事务长时间持有锁不释放,可以 kill 事务对应的线程 ID ,也就是 INNODB_TRX 表中的 trx_mysql_thread_id,例如执行 kill 4,kill 7,kill 8。

当然,死锁的问题不能每次都靠 kill 线程来解决,这是治标不治本的行为。我们应该尽量在应用端,也就是在编码的过程中避免。

有哪些可以避免死锁的方法呢?

死锁的避免

  1. 在程序中,操作多张表时,尽量以相同的顺序来访问(避免形成等待环路);
  2. 批量操作单张表数据的时候,先对数据进行排序(避免形成等待环路);
  3. 申请足够级别的锁,如果要操作数据,就申请排它锁;
  4. 尽量使用索引访问数据,避免没有 where 条件的操作,避免锁表;
  5. 如果可以,大事务化成小事务;
  6. 使用等值查询而不是范围查询查询数据,命中记录,避免间隙锁对并发的影响。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请联系我们举报,一经查实,本站将立刻删除。

发布者:全栈程序员-站长,转载请注明出处:https://javaforall.net/111631.html原文链接:https://javaforall.net

(0)
上一篇 2022年2月17日 下午9:00
下一篇 2022年2月17日 下午9:00


相关推荐

  • 《JavaScript设计模式》初次笔记——wsdchong[通俗易懂]

    《JavaScript设计模式》初次笔记——wsdchong[通俗易懂]《JavaScript设计模式》初次笔记前言设计模式一直久仰大名,但是没有去花时间去了解,于是今天特意花时间去看《JavaScript设计模式》(2013年6月出版)和w3cschool上的设计模式。然后做了一些笔记。以《JavaScript设计模式》为目录,以w3cschool上的设计模式为补充。讲的内容有三:设计模式、JavaScript设计模式、其他(模块化的JavaScript设计模式、jQuery设计模式、jQuery插件设计模式)。学习目的:尝试性地了解JavaScript设计模式,方

    2022年7月12日
    20
  • 双边滤波算法_双边滤波的原理

    双边滤波算法_双边滤波的原理双边滤波算法

    2022年8月4日
    11
  • 微信表情符号写入案件判决

    微信表情符号写入案件判决也留是说 你发的表情符号也是作为 呈堂证供 的依据了 普通人简单的交流总是容易被别有用心的人利用 就连日常的微信表情包都不放过 这不以后微信表情符号也有可能成为 呈堂证供 所以表情符号千万别乱用 容易为自己带来麻烦

    2026年3月19日
    2
  • 字符串的方法_js字符串包含另一个字符串

    字符串的方法_js字符串包含另一个字符串题目判断第一个字符串是否包含第二个字符串functionchange(str1,str2){if(str1===str2){returntrue}letarr1=[…str1]letarr2=[…str2]if(arr2.length>arr1.length){…

    2022年8月21日
    8
  • 长尾分布和重尾分布「建议收藏」

    长尾分布和重尾分布「建议收藏」文章来源:长尾分布,重尾分布(Heavy-tailedDistribution)-Shiyu_Huang-博客园https://www.cnblogs.com/huangshiyu13/p/6217180.html长尾分布,重尾分布(Heavy-tailedDistribution)Zipf分布:Zipf分布是一种符合长尾的分布:  就是指尾巴很长的分布。那么尾巴很长很厚的分布有什么特…

    2025年5月29日
    3
  • Linux 的 history 命令使用大全

    Linux 的 history 命令使用大全history命令history命令:用于显示历史记录和执行过的指令命令。history命令读取历史命令文件中的目录到历史命令缓冲区和将历史命令缓冲区中的目录写入命令文件。该命令单独使用时,仅显示历

    2022年7月4日
    25

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

关注全栈程序员社区公众号