我设法在我的时间内解决了许多僵局，而且他们通常涉及相反的ORDER BY条款，但是这个让我感到难过：
------------------------
LATEST DETECTED DEADLOCK
------------------------
2017-09-04 03:06:37 0x7fe24c089700
*** (1) TRANSACTION:
TRANSACTION 58577744, ACTIVE 1 sec fetching rows
mysql tables in use 1, locked 1
LOCK WAIT 5 lock struct(s), heap size 1136, 414 row lock(s)
MySQL thread id 1921752, OS thread handle 140609486370560, query id 50687761 localhost spikeatschool updating
UPDATE `image_gallery_categories` SET `position` = (`image_gallery_categories`.`position` + 1), `updated_at` = '2017-09-04 03:06:36.313021' WHERE `image_gallery_categories`.`image_gallery_id` = 997 AND `image_gallery_categories`.`startup` = 1
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 88146 page no 6 n bits 320 index PRIMARY of table `94e842b4c723600d`.`image_gallery_categories` trx id 58577744 lock_mode X waiting
Record lock, heap no 99 PHYSICAL RECORD: n_fields 10; compact format; info bits 32
0: len 4; hex 8000030a; asc ;;
1: len 6; hex 0000037dd321; asc } !;;
2: len 7; hex 60000003f52351; asc ` #Q;;
3: len 7; hex 4b69776963616e; asc Kiwican;;
4: len 0; hex ; asc ;;
5: len 4; hex 8000033e; asc >;;
6: len 4; hex 80000002; asc ;;
7: len 5; hex 999d38024b; asc 8 K;;
8: len 5; hex 999d8831a4; asc 1 ;;
9: len 1; hex 81; asc ;;
*** (2) TRANSACTION:
TRANSACTION 58577697, ACTIVE 23 sec starting index read
mysql tables in use 1, locked 1
26 lock struct(s), heap size 3520, 118 row lock(s), undo log entries 541
MySQL thread id 1923177, OS thread handle 140609914967808, query id 50687925 localhost spikeatschool updating
UPDATE `image_gallery_categories` SET `image_gallery_categories`.`updated_at` = '2017-09-04 03:06:37' WHERE `image_gallery_categories`.`id` = 771
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 88146 page no 6 n bits 320 index PRIMARY of table `94e842b4c723600d`.`image_gallery_categories` trx id 58577697 lock_mode X locks rec but not gap
Record lock, heap no 99 PHYSICAL RECORD: n_fields 10; compact format; info bits 32
0: len 4; hex 8000030a; asc ;;
1: len 6; hex 0000037dd321; asc } !;;
2: len 7; hex 60000003f52351; asc ` #Q;;
3: len 7; hex 4b69776963616e; asc Kiwican;;
4: len 0; hex ; asc ;;
5: len 4; hex 8000033e; asc >;;
6: len 4; hex 80000002; asc ;;
7: len 5; hex 999d38024b; asc 8 K;;
8: len 5; hex 999d8831a4; asc 1 ;;
9: len 1; hex 81; asc ;;
Record lock, heap no 104 PHYSICAL RECORD: n_fields 10; compact format; info bits 32
0: len 4; hex 80000311; asc ;;
1: len 6; hex 0000037dd321; asc } !;;
2: len 7; hex 60000003f519b8; asc ` ;;
3: len 23; hex 4e67c4812050c5ab72c4816b617520c481204dc4817569; asc Ng P r kau M ui;;
4: len 0; hex ; asc ;;
5: len 4; hex 8000033e; asc >;;
6: len 4; hex 80000001; asc ;;
7: len 5; hex 999d3802f8; asc 8 ;;
8: len 5; hex 999d8831a3; asc 1 ;;
9: len 1; hex 81; asc ;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 88146 page no 6 n bits 320 index PRIMARY of table `94e842b4c723600d`.`image_gallery_categories` trx id 58577697 lock_mode X locks rec but not gap waiting
Record lock, heap no 93 PHYSICAL RECORD: n_fields 10; compact format; info bits 0
0: len 4; hex 80000303; asc ;;
1: len 6; hex 000002d1715c; asc q\;;
2: len 7; hex 73000003df1872; asc s r;;
3: len 14; hex 4d616e7572657761204d61726165; asc Manurewa Marae;;
4: len 0; hex ; asc ;;
5: len 4; hex 8000033e; asc >;;
6: len 4; hex 80000003; asc ;;
7: len 5; hex 999d380226; asc 8 &;;
8: len 5; hex 999d3802f9; asc 8 ;;
9: len 1; hex 81; asc ;;
*** WE ROLL BACK TRANSACTION (1)
是否因为WHERE条款不同？我该如何减轻这个？ SQL是由Ruby on Rails生成的，所以我对它没有多少控制权。
更新 第一个事务查询之前唯一的其他查询是：
SELECT `image_gallery_category_images`.* FROM `image_gallery_category_images` WHERE `image_gallery_category_images`.`image_gallery_category_id` = 734 ORDER BY `image_gallery_category_images`.`position` ASC
由于COMMIT在上面一行，似乎没有开始交易。
另一个交易将此作为唯一的其他相关查询：
SELECT `image_gallery_categories`.* FROM `image_gallery_categories` WHERE `image_gallery_categories`.`id` = 771 LIMIT 1
每个请求的实际日志都是巨大的，因为它们正在做很多事情，因此很难将它们拼凑在一起。在这种情况下，Rails不必要地接触最终被删除的父表记录。需要充分研究，我认为我有一些线索可以避免这种情况发生。