LATEST DETECTED DEADLOCK
------------------------
2017-11-27 11:26:22 2b80ab881700
*** (1) TRANSACTION:
TRANSACTION 84983140, ACTIVE 3.138 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 13 lock struct(s), heap size 2936, 9 row lock(s), undo log entries 102
LOCK BLOCKING MySQL thread id: 4188408 block 4188409
MySQL thread id 4188409, OS thread handle 0x2b80c834c700, query id 1119236930 119.23.142.11
all5 update
INSERT INTO t_flow_real_time( `spot`,`group_quantity`,`booking`,`statistics_time` )
values ( 1,1,'2017-11-24','2017-11-27 11:26:21.007' )
ON DUPLICATE KEY UPDATE
`group_quantity` = group_quantity + 1
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1258 page no 4 n bits 104 index `idx_unique` of table `a_analysis`.`t_flow_real_time` trx id 84983140 lock_mode X waiting
Record lock, heap no 33 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 4; hex 80000001; asc ;;
1: len 3; hex 8fc378; asc x;;
2: len 4; hex 8000984d; asc M;;
*** (2) TRANSACTION:
TRANSACTION 84983143, ACTIVE 1.554 sec inserting
mysql tables in use 1, locked 1
13 lock struct(s), heap size 2936, 9 row lock(s), undo log entries 46
MySQL thread id 4188408, OS thread handle 0x2b80ab881700, query id 1119237503 119.23.142.11
all580 update
INSERT INTO t_flow_real_time ( `spot`, `group_quantity`, `booking`, `statistics_time` )
values ( 1, 1, '2017-11-26', '2017-11-27 11:26:22.407' )
ON DUPLICATE KEY UPDATE
`group_quantity` = group_quantity + 1
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 1258 page no 4 n bits 104 index `idx_unique` of table `a_analysis`.`t_flow_real_time` trx id 84983143 lock_mode X
Record lock, heap no 33 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 4; hex 80000001; asc ;;
1: len 3; hex 8fc378; asc x;;
2: len 4; hex 8000984d; asc M;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1258 page no 4 n bits 104 index `idx_unique` of table `a_analysis`.`t_flow_real_time` trx id 84983143 lock_mode X waiting
Record lock, heap no 34 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 4; hex 80000001; asc ;;
1: len 3; hex 8fc37a; asc z;;
2: len 4; hex 8000987b; asc {;;
*** WE ROLL BACK TRANSACTION (2)
uj5u.com熱心網友回復：
你應該把表結構先發一下。uj5u.com熱心網友回復：
補充表結構：Create Table
CREATE TABLE `t_flow_real_time` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主鍵',
`spot` int(11) DEFAULT NULL COMMENT '景區',
`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` date DEFAULT NULL COMMENT '游玩日期',
`statistics_time` datetime DEFAULT NULL COMMENT '統計時間',
PRIMARY KEY (`id`),
UNIQUE KEY `idx_unique` (`spot`,`booking`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=46451 DEFAULT CHARSET=utf8 COMMENT='客流實時資料'
uj5u.com熱心網友回復：
show processlist;查看死鎖發送時的sql
uj5u.com熱心網友回復：
日志是否有缺失呀？通過提供的日志分析出如下：
事務2（tx_id:84983143）應該有兩條SQL，用sql1和sql2表示。
sql1對應的idx_unique資料庫結構為：
hex 80000001
hex 8fc378
hex 8000984d
sql2對應的idx_unique資料庫結構為：
hex 80000001
hex 8fc37a
hex 8000987b
事務1（tx_id:84983140）從日志只看到一條SQL，用sql1表示。
sql1對應的idx_unique資料庫結構為：
hex 80000001
hex 8fc378
hex 8000984d
結果：
從日志分析能看出：
1、事務1 的sql1正在等待 事務2的sql1對應的二級索引(idx_unique(hex 80000001,hex 8000984d)）記錄上的X鎖。
2、事務2的sql2正在等待 另一個事務的sql=sql2對應的二級索引 (idx_unique(hex 80000001,hex 8000987b)）記錄上的X鎖。
因此出現事務1 等待 事務2， 而事務2 又等待 另一個事務的困境。若這里的 另一個事務 就是事務1的話，那就徹底死鎖了； 若另一個事務 是 事務3的話，那就只有等事務3釋放了事務2等待的X鎖，事務2執行后再釋放了事務1等待的X鎖，這時候事務1才可以正常執行。
通過附件附上分析程序，供參考指正。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/101076.html
標籤：MySQL
下一篇：請教多表查詢的實作方法