有大佬帮忙看一下这个死锁怎么形成的吗

Question

按道理主键+RR不会形成死锁啊

InnoDB: * WE ROLL BACK TRANSACTION (1)
InnoDB: * (2) WAITING FOR THIS LOCK TO BE GRANTED:
InnoDB: * (2) HOLDS THE LOCK(S):
InnoDB: * (2) TRANSACTION:
InnoDB: 
InnoDB: * (1) WAITING FOR THIS LOCK TO BE GRANTED:
InnoDB: Transactions deadlock detected, dumping detailed information.
update examinees set token = 'eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9leGFtLmNvZGVwa3UuY29tXC9hcGlcL2V4YW1pbmVlXC9sb2dpbiIsImlhdCI6MTU3NjM3MjE4MCwiZXhwIjoxNjEyMzcyMTgwLCJuYmYiOjE1NzYzNzIxODAsImp0aSI6Im15TGZ6NmhqVFJzYTNjb1EiLCJzdWIiOjg4NCwicHJ2IjoiNDY3MGJjYmM4YzU5NTJjZTdmN2ExZjQ4OTliOTU0YzU1YjU2NDMyZCJ9.pIIe2xY-eh_3_HhUOURdj325sq9Od1koOVPlRKZ6hXM', login_count = 7, last_login_at = '2019-12-15 09:09:40', examinees.updated_at = '2019-12-15 09:09:40' where id = 884
1: len 6; hex 0000003d236f; asc =#o;;
5: len 15; hex 38353836343036304071712e636f6d; asc [e-mail];;
14: len 30; hex 68747470733a2f2f6578616d2d313235333338363431342e66696c652e6d; asc https://exam-1253386414.file.m; (total 92 bytes);
10: len 18; hex 343431333233323030383130303333343131; asc 441323200810033411;;
14: len 30; hex 68747470733a2f2f6578616d2d313235333338363431342e66696c652e6d; asc https://exam-1253386414.file.m; (total 92 bytes);
RECORD LOCKS space id 301 page no 83 n bits 88 index PRIMARY of table exam.examinees trx id 4006767 lock_mode X locks rec but not gap waiting
Record lock, heap no 12 PHYSICAL RECORD: n_fields 27; compact format; info bits 0
3: len 9; hex e69d8ee59bbde7909b; asc ;;
25: len 4; hex 5d68cbfc; asc ]h ;;
18: len 24; hex e883a1e88081e5b888e280ad203135333237323433333934; asc 15327243394;;
7: len 30; hex 24327924313024526e656676315a48716755427072383455456c71732e45; asc $2y$10$Rnefv1ZHqgUBpr84UElqs.E; (total 60 bytes);
mysql tables in use 1, locked 1
LOCK WAIT 19 lock struct(s), heap size 1136, 8 row lock(s), undo log entries 224
3: len 6; hex e69cb1e888aa; asc ;;
7: len 30; hex 243279243130247756783376524c2e38756457306945644f6e5061734f53; asc $2y$10$wVx3vRL.8udW0iEdOnPasOS; (total 60 bytes);
* (1) TRANSACTION:
0: len 4; hex 00000374; asc t;;
13: len 0; hex ; asc ;;
22: len 4; hex 00000008; asc ;;
23: len 4; hex 5df58817; asc ] ;;
Record lock, heap no 19 PHYSICAL RECORD: n_fields 27; compact format; info bits 0
8: len 1; hex 01; asc ;;
18: len 24; hex e883a1e88081e5b888e280ad203135333237323433333934; asc 15327243394;;
11: len 1; hex 81; asc ;;
13: len 0; hex ; asc ;;
16: len 1; hex 81; asc ;;
20: len 4; hex 00000000; asc ;;
22: len 4; hex 00000004; asc ;;
24: SQL NULL;
6: len 11; hex 3133383032353838323832; asc 13802588282;;
21: len 30; hex 65794a30655841694f694a4b563151694c434a68624763694f694a49557a; asc eyJ0eXAiOiJKV1QiLCJhbGciOiJIUz; (total 337 bytes);
24: SQL NULL;
TRANSACTION 4006767, ACTIVE 1426 sec starting index read
19: len 4; hex 00000013; asc ;;
RECORD LOCKS space id 301 page no 28 n bits 88 index PRIMARY of table exam.examinees trx id 4005686 lock_mode X locks rec but not gap waiting
Record lock, heap no 19 PHYSICAL RECORD: n_fields 27; compact format; info bits 0
MySQL thread id 10516222, OS thread handle 139667263854336, query id 300969200 *.190 exam updating
10: len 18; hex 343431333233323030383130303333343131; asc 441323200810033411;;
11: len 1; hex 81; asc ;;
12: len 4; hex 00000000; asc ;;
16: len 1; hex 81; asc ;;
mysql tables in use 1, locked 1
MySQL thread id 10520696, OS thread handle 139667256985344, query id 301142683 *.190 exam updating
26: len 4; hex 5df58817; asc ] ;;
3: len 6; hex e69cb1e888aa; asc ;;
13: len 0; hex ; asc ;;
10: len 18; hex 343430333034323030383032303230343334; asc 440304200802020434;;
12: len 4; hex 00000000; asc ;;
17: len 1; hex 01; asc ;;
15: len 10; hex 323030382d31302d3033; asc 2008-10-03;;
19: len 4; hex 00000013; asc ;;
20: len 4; hex 00000000; asc ;;
7: len 30; hex 243279243130247756783376524c2e38756457306945644f6e5061734f53; asc $2y$10$wVx3vRL.8udW0iEdOnPasOS; (total 60 bytes);
9: len 30; hex 5b2268747470733a5c2f5c2f6578616d2d313235333338363431342e6669; asc ["https://exam-1253386414.fi; (total 205 bytes);
28 lock struct(s), heap size 3520, 28 row lock(s), undo log entries 1850
26: len 4; hex 5df58817; asc ] ;;
23: len 4; hex 5df5863f; asc ] ?;;
17: len 1; hex 02; asc ;;
26: len 4; hex 5df5863f; asc ] ?;;
RECORD LOCKS space id 301 page no 28 n bits 88 index PRIMARY of table exam.examinees trx id 4006767 lock_mode X locks rec but not gap
0: len 4; hex 00000374; asc t;;
4: len 9; hex e69e97e7bfa0e78fa0; asc ;;
15: len 10; hex 323030382d30322d3032; asc 2008-02-02;;
TRANSACTION 4005686, ACTIVE 1709 sec starting index read
2: len 7; hex 29000001cf11da; asc ) ;;
8: len 1; hex 01; asc ;;
4: len 9; hex e69e97e7bfa0e78fa0; asc ;;
5: len 15; hex 38353836343036304071712e636f6d; asc [e-mail];;
9: len 30; hex 5b2268747470733a5c2f5c2f6578616d2d313235333338363431342e6669; asc ["https://exam-1253386414.fi; (total 205 bytes);
18: len 24; hex e883a1e88081e5b888e280ad203135333237323433333934; asc 15327243394;;
6: len 11; hex 3138313239393331303638; asc 18129931068;;
14: len 30; hex 68747470733a2f2f6578616d2d313235333338363431342e66696c652e6d; asc https://exam-1253386414.file.m; (total 92 bytes);
update examinees set token = 'eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9leGFtLmNvZGVwa3UuY29tXC9hcGlcL2V4YW1pbmVlXC9sb2dpbiIsImlhdCI6MTU3NjM3MzQ1NCwiZXhwIjoxNjEyMzczNDU0LCJuYmYiOjE1NzYzNzM0NTQsImp0aSI6IlhXWmZNSUdNTjVLSTd6U0kiLCJzdWIiOjE2MjYsInBydiI6IjQ2NzBiY2JjOGM1OTUyY2U3ZjdhMWY0ODk5Yjk1NGM1NWI1NjQzMmQifQ.zUGTJnfnGREKzbkASKjVtPVaac_3bMXXUVuDs7vdDKE', login_count = 4, last_login_at = '2019-12-15 09:30:54', examinees.updated_at = '2019-12-15 09:30:54' where id = 1626
1: len 6; hex 0000003d236f; asc =#o;;
2: len 7; hex 29000001cf11da; asc ) ;;
25: len 4; hex 5d68cbfc; asc ]h ;;
6: len 11; hex 3138313239393331303638; asc 18129931068;;
15: len 10; hex 323030382d31302d3033; asc 2008-10-03;;
23: len 4; hex 5df58817; asc ] ;;
0: len 4; hex 0000065a; asc Z;;
11: len 1; hex 81; asc ;;
12: len 4; hex 00000000; asc ;;
15: len 10; hex 323030382d31302d3033; asc 2008-10-03;;
23: len 4; hex 5df58817; asc ] ;;
0: len 4; hex 0000065a; asc Z;;
9: len 30; hex 5b2268747470733a5c2f5c2f736372617463682d776f726b732d31323533; asc ["https://scratch-works-1253; (total 215 bytes);
21: len 30; hex 65794a30655841694f694a4b563151694c434a68624763694f694a49557a; asc eyJ0eXAiOiJKV1QiLCJhbGciOiJIUz; (total 337 bytes);
16: len 1; hex 81; asc ;;
21: len 30; hex 65794a30655841694f694a4b563151694c434a68624763694f694a49557a; asc eyJ0eXAiOiJKV1QiLCJhbGciOiJIUz; (total 339 bytes);
17: len 1; hex 01; asc ;;
4: len 6; hex e983ade99c9e; asc ;;
5: len 15; hex 31323038383438374071712e636f6d; asc [e-mail];;
19: len 4; hex 00000013; asc ;;
24: SQL NULL;
2: len 7; hex 38000001a3284a; asc 8 (J;;
20: len 4; hex 00000000; asc ;;
25: len 4; hex 5dea312c; asc ] 1,;;

Answer 1

这段代码中的死锁是由于两个事务分别持有了不同的记录锁，且等待对方的记录锁导致的。MySQL在发现死锁后会选择撤销其中一个事务来解决死锁问题，从而触发了一次数据回滚操作。根据信息看，事务4006767和事务4005686分别占用了examinees表中的不同记录，且它们都等待对方的记录锁释放。

具体解决方案是，对事务的执行顺序进行调整，使得它们分别按照相同的顺序访问事务所需要的记录，从而避免产生死锁的情况。同时，可以通过MySQL的事务隔离级别设置，如将隔离级别设置为READ_COMMITTED，从而避免一些潜在的死锁问题。