这个死锁原因是什么？

显示全部楼层 · 2021-1-27 06:42:18

LATESTDETECTEDDEADLOCK
------------------------
2017-11-2711:26:222b80ab881700
***(1)TRANSACTION:
TRANSACTION84983140,ACTIVE3.138secinserting
mysqltablesinuse1,locked1
LOCKWAIT13lockstruct(s),heapsize2936,9rowlock(s),undologentries102
LOCKBLOCKINGMySQLthreadid:4188408block4188409
MySQLthreadid4188409,OSthreadhandle0x2b80c834c700,queryid1119236930119.23.142.11
all5update
INSERTINTOt_flow_real_time(`spot`,`group_quantity`,`booking`,`statistics_time`)
values(1,1,'2017-11-24','2017-11-2711:26:21.007')
ONDUPLICATEKEYUPDATE
`group_quantity`=group_quantity+1
***(1)WAITINGFORTHISLOCKTOBEGRANTED:
RECORDLOCKSspaceid1258pageno4nbits104index`idx_unique`oftable`a_analysis`.`t_flow_real_time`trxid84983140lock_modeXwaiting
Recordlock,heapno33PHYSICALRECORD:n_fields3;compactformat;infobits0
0:len4;hex80000001;asc;;
1:len3;hex8fc378;ascx;;
2:len4;hex8000984d;ascM;;
***(2)TRANSACTION:
TRANSACTION84983143,ACTIVE1.554secinserting
mysqltablesinuse1,locked1
13lockstruct(s),heapsize2936,9rowlock(s),undologentries46
MySQLthreadid4188408,OSthreadhandle0x2b80ab881700,queryid1119237503119.23.142.11
all580update
INSERTINTOt_flow_real_time(`spot`,`group_quantity`,`booking`,`statistics_time`)
values(1,1,'2017-11-26','2017-11-2711:26:22.407')
ONDUPLICATEKEYUPDATE
`group_quantity`=group_quantity+1
***(2)HOLDSTHELOCK(S):
RECORDLOCKSspaceid1258pageno4nbits104index`idx_unique`oftable`a_analysis`.`t_flow_real_time`trxid84983143lock_modeX
Recordlock,heapno33PHYSICALRECORD:n_fields3;compactformat;infobits0
0:len4;hex80000001;asc;;
1:len3;hex8fc378;ascx;;
2:len4;hex8000984d;ascM;;
***(2)WAITINGFORTHISLOCKTOBEGRANTED:
RECORDLOCKSspaceid1258pageno4nbits104index`idx_unique`oftable`a_analysis`.`t_flow_real_time`trxid84983143lock_modeXwaiting
Recordlock,heapno34PHYSICALRECORD:n_fields3;compactformat;infobits0
0:len4;hex80000001;asc;;
1:len3;hex8fc37a;ascz;;
2:len4;hex8000987b;asc{;;
***WEROLLBACKTRANSACTION(2)
分 -->

千问 · 2021-1-27 06:42:18

你应该把表结构先发一下。

千问 · 2021-1-27 06:42:18

补充表结构：

CreateTable
CREATETABLE`t_flow_real_time`(
`id`int(11)NOTNULLAUTO_INCREMENTCOMMENT'主键',
`spot`int(11)DEFAULTNULLCOMMENT'景区',
`group_quantity`int(11)DEFAULT'0'COMMENT'今日团队人数',
`quantity`int(11)DEFAULT'0'COMMENT'今日票数',
`consume_quantity`int(11)DEFAULT'0'COMMENT'核销数量',
`consume_group_quantity`int(11)DEFAULT'0'COMMENT'核销团队人数',
`refund_quantity`int(11)DEFAULT'0'COMMENT'退票数',
`refund_group_quantity`int(11)DEFAULT'0'COMMENT'退票团队人数',
`booking`dateDEFAULTNULLCOMMENT'游玩日期',
`statistics_time`datetimeDEFAULTNULLCOMMENT'统计时间',
PRIMARYKEY(`id`),
UNIQUEKEY`idx_unique`(`spot`,`booking`)USINGBTREE
)ENGINE=InnoDBAUTO_INCREMENT=46451DEFAULTCHARSET=utf8COMMENT='客流实时数据'

千问 · 2021-1-27 06:42:18

showprocesslist;
查看死锁发送时的sql

千问 · 2021-1-27 06:42:18

日志是否有缺失呀？通过提供的日志分析出如下：
事务2（tx_id:84983143）应该有两条SQL，用sql1和sql2表示。
sql1对应的idx_unique数据库结构为：
hex80000001
hex8fc378
hex8000984d
sql2对应的idx_unique数据库结构为：
hex80000001
hex8fc37a
hex8000987b
事务1（tx_id:84983140）从日志只看到一条SQL，用sql1表示。
sql1对应的idx_unique数据库结构为：
hex80000001
hex8fc378
hex8000984d
结果：
从日志分析能看出：
1、事务1的sql1正在等待事务2的sql1对应的二级索引(idx_unique(hex80000001,hex8000984d)）记录上的X锁。
2、事务2的sql2正在等待另一个事务的sql=sql2对应的二级索引(idx_unique(hex80000001,hex8000987b)）记录上的X锁。
因此出现事务1等待事务2，而事务2又等待另一个事务的困境。若这里的另一个事务就是事务1的话，那就彻底死锁了；若另一个事务是事务3的话，那就只有等事务3释放了事务2等待的X锁，事务2执行后再释放了事务1等待的X锁，这时候事务1才可以正常执行。
通过附件附上分析过程，供参考指正。