使用终端或命令提示符登录到MySQL，输入命令：
mysql -h xxxx.xxx.xxx -P 3306 -u username -p password
2
在MySQL客户端下输入命令：
show engine innodb status \G
3
在打印出来的信息中找到“LATEST DETECTED DEADLOCK”一节内容
4
多线程开启事务处理。每个事务有多个update *** 作和一个insert *** 作（都在同一张表）。
默认隔离级别：Repeatable Read
只有hotel_id=2和hotel_id=11111的数据
逻辑删除原有数据
插入新的数据
根据现有数据情况，update的时候没有数据被更新
报了非常多一样的错
发现居然有死锁。
根据常识考虑，我每个线程（事务）更新的数据都不冲突，为什么会产生死锁？
带着这个问题，打印mysql最近一次的死锁信息
show engine innodb status
显示如下
发现事务1在等待一个锁
事务2也在等待一个锁
而且事物2持有了事物1需要的锁
关于锁的描述，出现了 lock_mode ， gap before rec ， insert intention 等字眼，看不懂说明了什么？说明我关于mysql的锁相关的知识储备还不够。那就开始调查mysql的锁相关知识。
通过搜索引擎，
锁的持有兼容程度如下表
那么再回到死锁日志，可以知道 :
事务1正在获取插入意向锁
事务2正在获取插入意向锁，持有排他gap锁
再看我们上面的锁兼容表格，可以知道， gap lock和insert intention lock是不兼容的
那么就可以推断出： 事务1持有gap lock，等待事务2的insert intention lock释放；事务2持有gap lock，等待事务1的insert intention lock释放，从而导致死锁。
那么新的问题就来了，事务1的intention lock 为什么会和事务2的gap lock 有交集，或者说，事务1要插入的数据的位置为什么会被事务2给锁住？
让我回顾一下gap lock的定义：
间隙锁，锁定一个范围，但不包括记录本身。GAP锁的目的，是为了防止同一事务的两次当前读，出现幻读的情况
那为什么是gap lock，gap lock到底是基于什么逻辑锁的记录？发现自己相关的知识储备还不够。那就开始调查。
调查后发现，当当前索引是一个 普通索引 的时候，会加一个gap lock来防止幻读， 此gap lock 会锁住一个左开右闭的区间。 假设索引为xx_idx（xx_id），数据分布为1,4,6,8,12，当更新xx_id=9的时候，这个时候gap lock的锁定记录区间就是(8，12]，也就是锁住了xxid in (9,10,11,12)的数据，当有其他事务要插入xxid in (9,10,11,12)的数据时，就会处于等待获取锁的状态。
ps：当前索引不是普通索引，而且是唯一索引等其他情况，请参考下面资料
MySQL 加锁处理分析
回到我自己的案例中，重新屡一下事务1的执行过程：
因为普通索引
KEY hotel_date_idx ( hotel_id , rate_date )
的关系 这段sql会获取一个gap lock，范围(2,11111]
这段sql会获取一个insert intention lock （waiting）
再看事务2的执行过程
因为普通索引
KEY hotel_date_idx ( hotel_id , rate_date )
的关系 这段sql也会获取一个gap lock，范围也是(2,11111]（根据前面的知识，gap lock之间会互相兼容，可以一起持有锁的）
这段sql也会获取一个insert intention lock （waiting）
看到这里，基本也就破案了。因为普通索引的关系，事务1和事务2的gap lock的覆盖范围太广，导致其他事务无法插入数据。
重新梳理一下：
所以从结果来看，一堆事务被回滚，只有10007数据被更新成功
gap lock 导致了并发处理的死锁
在mysql默认的事务隔离级别（repeatable read）下，无法避免这种情况。只能把并发处理改成同步处理。或者从业务层面做处理。
共享锁、排他锁、意向共享、意向排他
record lock、gap lock、next key lock、insert intention lock
show engine innodb status
在之前的版本，要查看死锁，你要show engine innodb status\G在MySQL5.6版本，在my.cnf配置文件里，加入
innodb_print_all_deadlocks = 1
就可以把死锁信息打印到错误日志里。
下面是一个死锁演示：。。。。略
# more mysql5_6.err
121012 10:33:40 [Note]
/usr/local/mysql/bin/mysqld: ready for connections.
Version:
'5.6.6-m9-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Server
（GPL）
InnoDB: transactions deadlock detected, dumping detailed
information.
121012 10:35:07
*** （1） TRANSACTION:
TRANSACTION 304904, ACTIVE 49 sec starting index read
mysql tables in use
1, locked 1
LOCK WAIT 3 lock struct（s）， heap size 320, 2 row lock（s），
undo log entries 1
MySQL thread id 1, OS thread handle 0x9106cb90, query
id 13 localhost root updating
update t2 set name='cc1' where id=3
*** （1） WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1201
page no 3 n bits 80 index `PRIMARY` of table `test`.`t2` trx id 304904 lock_mode
X locks rec but not gap waiting
Record lock, heap no 12 PHYSICAL RECORD:
n_fields 4compact formatinfo bits 0
0: len 4hex 80000003asc
1: len 6hex 00000004a709asc
2: len 7hex
09000002f401caasc
3: len 2hex 6363asc cc
*** （2）
TRANSACTION:
TRANSACTION 304905, ACTIVE 15 sec starting index read
mysql tables in use 1, locked 1
3 lock struct（s）， heap size 320, 2 row
lock（s）， undo log entries 1
MySQL thread id 2, OS thread handle
0x9103bb90, query id 14 localhost root updating
update t2 set name='bb1'
where id=2
*** （2） HOLDS THE LOCK（S）：
RECORD LOCKS space id 1201
page no 3 n bits 80 index `PRIMARY` of table `test`.`t2` trx id 304905 lock_mode
X locks rec but not gap
Record lock, heap no 12 PHYSICAL RECORD: n_fields
4compact formatinfo bits 0
0: len 4hex 80000003asc
1: len 6hex 00000004a709asc
2: len 7hex 09000002f401ca
asc
3: len 2hex 6363asc cc
*** （2） WAITING FOR
THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1201 page no 3 n bits 80
index `PRIMARY` of table `test`.`t2` trx id 304905 lock_mode X locks rec but not
gap waiting
Record lock, heap no 11 PHYSICAL RECORD: n_fields 4compact
formatinfo bits 0
0: len 4hex 80000002asc
1: len 6
hex 00000004a708asc
2: len 7hex 08000002522e5casc
R.\
3: len 2hex 6262asc bb
*** WE ROLL BACK TRANSACTION
（2）
参见手册：
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）