并发情况下 偶尔会出现死锁

[lipanda3658]

TRANSACTION 18343728, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 6 lock struct(s), heap size 1128, 4 row lock(s), undo log entries 1
MySQL thread id 565458, OS thread handle 140486039254784, query id 56005324 10.42.1.159 root update
INSERT INTO trans_branch_op (create_time,update_time,gid,url,bin_data,branch_id,op,status,finish_time,rollback_time) VALUES ('2023-11-18 18:48:37.411163915','2023-11-18 18:48:37.411163915','89MNrh7oETDeEoywMLRy4P','',NULL,'02','confirm','succeed','2023-11-18 18:48:37.332173483',NULL),('2023-11-18 18:48:37.411163915','2023-11-18 18:48:37.411163915','89MNrh7oETDeEoywMLRy4P','',NULL,'01','confirm','succeed','2023-11-18 18:48:37.349310755',NULL) ON DUPLICATE KEY UPDATE status=VALUES(status),finish_time=VALUES(finish_time),update_time=VALUES(update_time)

*** (1) HOLDS THE LOCK(S):
RECORD LOCKS space id 133 page no 52242 n bits 88 index PRIMARY of table dtm.trans_branch_op trx id 18343728 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 133 page no 52242 n bits 88 index PRIMARY of table dtm.trans_branch_op trx id 18343728 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;

*** (2) TRANSACTION:
TRANSACTION 18343729, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 5 lock struct(s), heap size 1128, 4 row lock(s), undo log entries 1
MySQL thread id 565497, OS thread handle 140474828551936, query id 56005325 10.42.0.228 root update
INSERT INTO trans_branch_op (create_time,update_time,gid,url,bin_data,branch_id,op,status,finish_time,rollback_time) VALUES ('2023-11-18 18:48:37.412138','2023-11-18 18:48:37.412138','xKFWYNGcBTquGH4BrUBt8D','',NULL,'02','confirm','succeed','2023-11-18 18:48:37.333966299',NULL),('2023-11-18 18:48:37.412138','2023-11-18 18:48:37.412138','xKFWYNGcBTquGH4BrUBt8D','',NULL,'01','confirm','succeed','2023-11-18 18:48:37.350270487',NULL) ON DUPLICATE KEY UPDATE status=VALUES(status),finish_time=VALUES(finish_time),update_time=VALUES(update_time)

*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 133 page no 52242 n bits 88 index PRIMARY of table dtm.trans_branch_op trx id 18343729 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 133 page no 52242 n bits 88 index PRIMARY of table dtm.trans_branch_op trx id 18343729 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;

*** WE ROLL BACK TRANSACTION (2)

TRANSACTIONS

[yedf2]

帮忙给一个能够复现的例子项目，目前你出现的这个情况很奇怪，按道理，这些SQL执行的时间都很短，即使有锁争抢，也是非常小范围的，不应该最后是死锁

[lipanda3658]

感谢你的回答 我在想办法复现 如果能复现出来我会给出例子的