Я пытаюсь понять тупики, которые я испытываю, но последний из них поставил меня в тупик. Вот (в SHOW ENGINE INNODB STATUS \G;):
------------------------
LATEST DETECTED DEADLOCK
------------------------
2019-10-17 06:37:09 xxxxx
*** (1) TRANSACTION:
TRANSACTION xxxxx, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 42864609, OS thread handle 140344598791936, query id 1001312229 xx.xx.xx.xx user updating
DELETE FROM users WHERE device = 'A9C15FE8-BFF8-4D84-8B56-57FA74A0801E'
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1442 page no 445 n bits 304 index device_id of table `web`.`users` trx id 817645713 lock_mode X locks rec but not gap waiting
Record lock, heap no 233 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
0: len 30; hex 41384331354645372d424646382d344438342d384235362d353746413734; asc A8C15FE7-BFF8-4D84-8B56-57FA74; (total 36 bytes);
1: len 4; hex 8009870b; asc ;;
*** (2) TRANSACTION:
TRANSACTION 817645714, ACTIVE 0 sec starting index read, thread declared inside InnoDB 1
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 42864607, OS thread handle 140344597989120, query id 1001312230 xx.xx.xx.xx user updating
DELETE FROM users WHERE device = 'A9C15FE8-BFF8-4D84-8B56-57FA74A0801E'
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 1442 page no 445 n bits 304 index device_id of table `web`.`users` trx id 817645714 lock_mode X locks rec but not gap
Record lock, heap no 233 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
0: len 30; hex 41384331354645372d424646382d344438342d384235362d353746413734; asc A8C15FE7-BFF8-4D84-8B56-57FA74; (total 36 bytes);
1: len 4; hex 8009870b; asc ;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1442 page no 445 n bits 304 index device_id of table `web`.`users` trx id 817645714 lock_mode X waiting
Record lock, heap no 233 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
0: len 30; hex 41384331354645372d424646382d344438342d384235362d353746413734; asc A8C15FE7-BFF8-4D84-8B56-57FA74; (total 36 bytes);
1: len 4; hex 8009870b; asc ;;
*** WE ROLL BACK TRANSACTION (1)
Я использую PHP PDO, но транзакция не запускается с использованием $DB->beginTransaction(); для этого запроса, поэтому я не совсем понимаю, почему можно 'бегать за другим. Конечно, при условии, что это вне транзакции, не имеет значения, в каком порядке выполняются запросы?
Да, в этом случае не имеет значения, что один из запросов откатывается, потому что другой будет выполняться,но я все же хотел бы понять, почему в первую очередь возникает взаимоблокировка.
Кроме того, транзакция 1 откатывается, несмотря на то, что у нее более низкий идентификатор запроса. Конечно, сначала был запущен нижний идентификатор запроса, поэтому он должен быть «победителем»?
Возможно, есть вариант конфигурации, который я должен рассмотреть?
Заранее большое спасибо за любой совет, который вы получили!