多线程开启事务处理.每个事务有多个update操作和一个insert操作（都在同一张表）.
默认隔离级别：Repeatable Read
逻辑删除原有数据
插入新的数据
根据现有数据情况,update的时候没有数据被更新
报了非常多一样的错
发现居然有死锁.
根据常识考虑,我每个线程（事务）更新的数据都不冲突,为什么会产生死锁?
带着这个问题,打印mysql最近一次的死锁信息
show engine innodb status
显示如下
发现事务1在等待一个锁
关于锁的描述,出现了 lock_mode , gap before rec , insert intention 等字眼,看不懂说明了什么?说明我关于mysql的锁相关的知识储备还不够.那就开始调查mysql的锁相关知识.
通过搜索引擎,
锁的持有兼容程度如下表
那么再回到死锁日志,可以知道 :
事务1正在获取插入意向锁
再看我们上面的锁兼容表格,可以知道, gap lock和insert intention lock是不兼容的
让我回顾一下gap lock的定义：
间隙锁,锁定一个范围,但不包括记录本身.GAP锁的目的,是为了防止同一事务的两次当前读,出现幻读的情况
那为什么是gap lock,gap lock到底是基于什么逻辑锁的记录?发现自己相关的知识储备还不够.那就开始调查.
ps：当前索引不是普通索引,而且是唯一索引等其他情况,请参考下面资料
MySQL 加锁处理分析
回到我自己的案例中,重新屡一下事务1的执行过程：
因为普通索引
KEY hotel_date_idx ( hotel_id , rate_date )
这段sql会获取一个insert intention lock （waiting）
这段sql也会获取一个insert intention lock （waiting）
重新梳理一下：
gap lock 导致了并发处理的死锁
在mysql默认的事务隔离级别（repeatable read）下,无法避免这种情况.只能把并发处理改成同步处理.或者从业务层面做处理.
共享锁、排他锁、意向共享、意向排他
record lock、gap lock、next key lock、insert intention lock
mysql数据库死锁解决方法如下：
官方定义如下：两个事务都持有对方需要的锁,并且在等待对方释放,并且双方都不会释放自己的锁.
这个就好比你有一个人质,对方有一个人质,你们俩去谈判说换人.你让对面放人,对面让你放人.
看到这里,也许你会有这样的疑问,事务和谈判不一样,为什么事务不能使用完锁之后立马释放呢?居然还要操作完了之后一直持有锁?这就涉及到 MySQL 的并发控制了.
官方定义：
对应到 MySQL 上分为两个阶段：
就是说呢,只有遵循两段锁协议,才能实现 可串行化调度 .
但是两阶段锁协议不要求事务必须一次将所有需要使用的数据加锁,并且在加锁阶段没有顺序要求,所以这种并发控制方式会形成死锁.
MySQL有两种死锁处理方式：
由于性能原因,一般都是使用死锁检测来进行处理死锁.
死锁检测的原理是构建一个以事务为顶点、锁为边的有向图,判断有向图是否存在环,存在即有死锁.
检测到死锁之后,选择插入更新或者删除的行数最少的事务回滚,基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段来判断.
MySQL如何处理死锁
第一段：show ENGINE INNODB status
查看死锁位置,分析.
第二段：
首先解决死锁可以从死锁发生的条件入手,最容易解决的就是更改获取资源的顺序；
其次是避免长事务,让事务执行的时间尽可能少,让事务的覆盖范围尽可能小,长事务会导致并发度降低,且会有更多的SQL查 询延迟；
给整个方法加事务是否是必须的?可以不加事务的尽量不加.
可直接在mysql命令行执行：show engine innodb status\G;查看造成死锁的sql语句,分析索引情况,然后优化sql然后show processlist;另外可以打开慢查询日志,linux下打开需在my.cnf的[mysqld]里面加上以下内容：
可直接在mysql命令行执行:show engine innodb status\G; 查看造成死锁的sql语句,分析索引情况,然后优化sql然后show processlist; 另外可以打开慢查询日志,linux下打开需在...
以上就是土嘎嘎小编为大家整理的mysql怎么处理死锁相关主题介绍,如果您觉得小编更新的文章只要能对粉丝们有用,就是我们最大的鼓励和动力,不要忘记讲本站分享给您身边的朋友哦！！