Почему это тупик (MySQL использует InnoDB) - PullRequest
Новая
       5

Почему это тупик (MySQL использует InnoDB)

3 голосов
/ 28 сентября 2010

ПОКАЗАТЬ INNODB СТАТУС ДВИГАТЕЛЯ показывает мне это и называет это тупиком: 


LATEST DETECTED DEADLOCK

100923 22:29:21
* (1) TRANSACTION:
TRANSACTION 0 5335752, ACTIVE 0 sec, OS thread id 7992 inserting
mysql tables in use 1, locked 1
LOCK WAIT 5 lock struct(s), heap size 1024, 4 row lock(s), undo log entries 3
MySQL thread id 26, query id 14422 localhost 127.0.0.1 root update
insert into history_messagearguments (history_id, messageArguments_ORDER, messageArguments) values (69, 1, '1')
* (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 179145 n bits 304 index fk_history_msgargs of table zvs_rkl_01_test.history_messagearguments trx id 0 5335752 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 198 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 8; hex 8000000000000048; asc        H;; 1: len 6; hex 0000006fe7c5; asc    o  ;;

* (2) TRANSACTION:
TRANSACTION 0 5335748, ACTIVE 0 sec, OS thread id 6988 inserting, thread declared inside InnoDB 500
mysql tables in use 1, locked 1
5 lock struct(s), heap size 1024, 3 row lock(s), undo log entries 2
MySQL thread id 25, query id 14424 localhost 127.0.0.1 root update
insert into history_messagearguments (history_id, messageArguments_ORDER, messageArguments) values (71, 0, '0')
* (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 179145 n bits 304 index fk_history_msgargs of table zvs_rkl_01_test.history_messagearguments trx id 0 5335748 lock_mode X locks gap before rec
Record lock, heap no 198 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 8; hex 8000000000000048; asc        H;; 1: len 6; hex 0000006fe7c5; asc    o  ;;

* (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 179145 n bits 304 index fk_history_msgargs of table zvs_rkl_01_test.history_messagearguments trx id 0 5335748 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 198 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 8; hex 8000000000000048; asc        H;; 1: len 6; hex 0000006fe7c5; asc    o  ;;

* WE ROLL BACK TRANSACTION (2)

Я не могу понять, почему это тупик.Для транзакции 1 не существует строки «В ожидании этой блокировки:». Если транзакция 1 не удерживает никаких блокировок, она не может никого блокировать, поэтому она не может быть частью тупика.

Более теоретически, я не вижу, чтобы условие 4 выполнялось, как написано здесь: http://en.wikipedia.org/wiki/Deadlock#Necessary_conditions

В моем понимании, MySQL должен позволить транзакции 2 продолжаться.После завершения транзакция 1 может продолжаться.

Здесь (/1295530/mysql-tupikovoe-obyasnenie-neobhodimo) BrainCore писал:

Транзакция 2 «застревает» за запросом транзакции 1, как очередь FIFO.

Может кто-нибудь указать мне на документацию MySQL, чтобы подтвердить это? Мне трудно поверить, что транзакции выполняются строго в порядке их поступления.

Перед всеми вопросами о таблицеотображаются макет, уровень изоляции и т. д. Сейчас я не прошу помощи по устранению тупика. Я спрашиваю, как прочитать ВЫХОДНОЙ СТАТУС СТАТУСА ДВИГАТЕЛЯ.

1 Ответ

0 голосов
/ 28 сентября 2010

Считать транзакции 1 и 2: Читайте с конца до начала:

  • какой тип и почему: lock_mode X блокирует пробел перед ожиданием вставки записи
  • что заблокировано: RECORD LOCKS id места 0 страница нет 179145 n битов 304 индекс fk_history_msgargs таблицы zvs_rkl_01_test.history_messagearguments trx id 0 5335748
  • В ожидании этого замка будет предоставлен

InnoDB имеет проблемы с одновременной записью, особенно если вы вставляете данные в конец таблицы innodb.

...