内容简介:死锁的本质是资源竞争,批量插入如果顺序不一致很容易导致死锁,我们来分析一下这个情况。为了方便演示,把批量插入改写为了多条 insert。先来做几个小实验,简化的表结构如下在记录不存在的情况下,两个同样顺序的批量 insert 同时执行,第二个会进行锁等待状态
死锁的本质是资源竞争,批量插入如果顺序不一致很容易导致死锁,我们来分析一下这个情况。为了方便演示,把批量插入改写为了多条 insert。
先来做几个小实验,简化的表结构如下
CREATE TABLE `t1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `a` varchar(5), `b` varchar(5), PRIMARY KEY (`id`), UNIQUE KEY `uk_name` (`a`,`b`) ); 复制代码
实验1:
在记录不存在的情况下,两个同样顺序的批量 insert 同时执行,第二个会进行锁等待状态
t1 | t2 | |
---|---|---|
begin; | begin; | |
insert ignore into t1(a, b)values("1", "1"); | 成功 | |
insert ignore into t1(a, b)values("1", "1"); | 锁等待状态 |
可以看到目前锁的状态
mysql> select * from information_schema.innodb_locks; +-------------+-------------+-----------+-----------+------------+------------+------------+-----------+----------+-----------+ | lock_id | lock_trx_id | lock_mode | lock_type | lock_table | lock_index | lock_space | lock_page | lock_rec | lock_data | +-------------+-------------+-----------+-----------+------------+------------+------------+-----------+----------+-----------+ | 31AE:54:4:2 | 31AE | S | RECORD | `d1`.`t1` | `uk_name` | 54 | 4 | 2 | '1', '1' | | 31AD:54:4:2 | 31AD | X | RECORD | `d1`.`t1` | `uk_name` | 54 | 4 | 2 | '1', '1' | +-------------+-------------+-----------+-----------+------------+------------+------------+-----------+----------+-----------+ 复制代码
在我们执行事务 t1
的 insert 时,没有在任何锁的断点处出现,这跟 MySQL 插入的原理有关系
insert 加的是隐式锁。什么是隐式锁?隐式锁的意思就是没有锁
在 t1 插入记录时,是不加锁的。这个时候事务 t1 还未提交的情况下,事务 t2 尝试插入的时候,发现有这条记录,t2 尝试获取 S 锁,会判定记录上的事务 id 是否活跃,如果活跃的话,说明事务未结束,会帮 t1 把它的 隐式锁
提升为 显式锁
( X 锁)
源码如下
t2 获取 S
锁的结果: DB_LOCK_WAIT
实验2:
批量插入顺序不一致的导致的死锁
t1 | t2 | |
---|---|---|
begin | ||
insert into t1(a, b)values("1", "1"); | 成功 | |
insert into t1(a, b)values("2", "2"); | 成功 | |
insert into t1(a, b)values("2", "2"); | t1 尝试获取 S 锁,把 t2 的隐式锁提升为显式 X 锁,进入 DB_LOCK_WAIT | |
insert into t1(a, b)values("1", "1"); | t2 尝试获取 S 锁,把 t1 的隐式锁提升为显式 X 锁,产生死锁 |
------------------------ LATEST DETECTED DEADLOCK ------------------------ 181101 9:48:36 *** (1) TRANSACTION: TRANSACTION 3309, ACTIVE 215 sec inserting mysql tables in use 1, locked 1 LOCK WAIT 3 lock struct(s), heap size 376, 2 row lock(s), undo log entries 2 MySQL thread id 2, OS thread handle 0x70000a845000, query id 58 localhost root update insert into t1(a, b)values("2", "2") *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 55 page no 4 n bits 72 index `uk_name` of table `d1`.`t1` trx id 3309 lock mode S waiting Record lock, heap no 3 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 1; hex 32; asc 2;; 1: len 1; hex 32; asc 2;; 2: len 4; hex 80000002; asc ;; *** (2) TRANSACTION: TRANSACTION 330A, ACTIVE 163 sec inserting mysql tables in use 1, locked 1 3 lock struct(s), heap size 376, 2 row lock(s), undo log entries 2 MySQL thread id 3, OS thread handle 0x70000a888000, query id 59 localhost root update insert into t1(a, b)values("1", "1") *** (2) HOLDS THE LOCK(S): RECORD LOCKS space id 55 page no 4 n bits 72 index `uk_name` of table `d1`.`t1` trx id 330A lock_mode X locks rec but not gap Record lock, heap no 3 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 1; hex 32; asc 2;; 1: len 1; hex 32; asc 2;; 2: len 4; hex 80000002; asc ;; *** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 55 page no 4 n bits 72 index `uk_name` of table `d1`.`t1` trx id 330A lock mode S waiting Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 1; hex 31; asc 1;; 1: len 1; hex 31; asc 1;; 2: len 4; hex 80000001; asc ;; *** WE ROLL BACK TRANSACTION (2) 复制代码
怎么样解决这样的问题呢? 一个可行的办法是在应用层 排序 以后再插入
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
银行3.0:移动互联时代的银行转型之道
[澳]布莱特·金(Brett King) / 白 宫 施 轶 / 广东经济出版社 / 2014-12 / 88.00元
银行未来会怎样,银行下一步该怎么做?银行如何在客户行为变化、科技变化,以及新的非银行竞争者不断涌入等时代变化的形势下,在未来取得成功? 这是第一本透彻深入地全面呈现当今银行业的内外形势与状况的书,内容涉及技术变化、客户行为变化、涌现的外部竞争者,银行现有组织架构、流程模式、制度思维、人员结构、互动渠道、营销方式等。具体包括低网点化,ATM、网站、呼叫中心的落伍,以及智能手机、社交媒体、移动支......一起来看看 《银行3.0:移动互联时代的银行转型之道》 这本书的介绍吧!