MySQL死锁

一时失言乱红尘 2024-03-31 08:16 97阅读 0赞

参考博客： https://blog.csdn.net/sinat\_41653656/article/details/109629094

### Mysql 锁类型和加锁分析 ###

MySQL有三种锁的级别：页级、表级、行级。  
**表级锁**：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。  
**行级锁**：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。（**sql修改数据用的行级锁**）  
**页面锁**：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度  
算法：  
next KeyLocks锁，同时锁住记录(数据)，并且锁住记录前面的Gap  
Gap锁，不锁记录，仅仅记录前面的Gap  
Recordlock锁（锁数据，不锁Gap）（排他锁）  
所以其实 Next-KeyLocks=Gap锁+ Recordlock锁  
![在这里插入图片描述][aa242930a1af481ba9cbcdd7835b44ab.png]  
![在这里插入图片描述][5445608ae90c41ffb4bdbfcc94ce32c3.jpeg_pic_center]

### 死锁产生原因和示例 ###

**产生原因**  
所谓死锁：是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用，它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。表级锁不会产生死锁.所以解决死锁主要还是针对于最常用的InnoDB。  
**死锁的关键在于：两个(或以上)的Session（会话）加锁的顺序不一致。  
那么对应的解决死锁问题的关键就是：让不同的session（会话）加锁有次序**  
产生示例  
参考博客：https://z.itpub.net/article/detail/06642B37065AE1C2D3B6BD46290A2B4A

**如果update、delete的事务操作用了不同的访问顺序，就会出现死锁。**

### 数据库中的锁机制以及死锁产生的原因及解决办法 ###

参考博客：https://blog.csdn.net/ziyonghong/article/details/104878247  
**死锁1:**

用户A访问表A（锁住了表A），然后又访问表B；用户B访问表B，然后企图访问表A；这时候用户A和B就会相互等待对方释放原本持有的锁，而进入僵持，也就死锁了。

**解决方法：对于多表的操作，尽力按照相同的顺序进行处理，避免同时锁定两个资源。必须同时锁定两个资源时，要保证在任何时刻都应该按照想同的顺序来锁定资源。比如让用户A先锁定表A再表B，那用户B也是先锁定表A再B。**

**死锁2:**  
用户A查询一条记录，然后修改这条记录；这时用户B修改这条记录。 用户A的事务里锁从查询的共享锁企图上升到独占锁，而用户B里的独占锁由于A有共享锁存在所以必须等A释放掉共享锁，但A由于B的独占锁无法上锁到独占锁也就不可能释放共享锁，于是就出现了死锁。

**解决方法:  
1.避免同时对同一条记录操作。  
2.使用乐观锁（基于数据版本记录机制）控制。  
3.使用悲观锁控制（开销比较大）。**

**死锁3:**  
**产生死锁的原因之一：update、delete的事务操作用不同的访问顺序**  
如果在事务中执行了一条不满足条件的update或delete语句，则执行全表扫描，把行级锁上升为表级锁，多个这样的事务执行后，很容易产生死锁和阻塞。当表中的数据量非常大而索引建的过少或不合适时候，也会经常发生全表扫描，出现类似情况。

**解法方法:SQL语句中不要使用太复杂的关联多表的查询，使用“explain”对SQL语句进行分析，对于全表扫描的SQL语句，建立相应的索引进行优化。唯一索引字段（最好是主键）按照特定序列排序，因为有索引，可以避免delete、update因为表级锁产生的死锁**

[aa242930a1af481ba9cbcdd7835b44ab.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/e4024078092642058ddd87bfe4942700.png
[5445608ae90c41ffb4bdbfcc94ce32c3.jpeg_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/31/19b36e1a76fb4c0f9d8955de0c357fa6.jpeg