Почему этот тупик произошел в MySQL?

Question

Я использую JMeter для тестирования своей программы, так как общее число ответов перестает расти, а затем я обнаруживаю тупик в MySQL.Я не понимаю, что означает ниже журнал.Кажется, что transaction(2) владел блокировкой S и пытался владеть блокировкой X той же таблицы.Это вызывает тупик?Если так, почему это произойдет?

ATEST DETECTED DEADLOCK
------------------------
2019-01-02 14:38:27 0x70000f30a000
*** (1) TRANSACTION:
TRANSACTION 24004, ACTIVE 0 sec inserting
mysql tables in use 2, locked 2
LOCK WAIT 5 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 2
MySQL thread id 11953, OS thread handle 123145549275136, query id 418447 localhost 127.0.0.1 username executing
INSERT INTO MRBS_SCHEDULE (ID,START_TIME,END_TIME,ROOM_ID,CREATE_BY,PRESIDE,REPEAT_ID,DESCRIPTION,NUM,TITLE,PRESIDE_EMAIL,PROJECTOR,CONFERENCE_CALL,CREATE_ID,BOOK_TIME,END_TYPE,EXPECTED_END_TIME) select null,'2019-01-03 19:53:00','2019-01-03 19:53:00',10113558,'d','d',12245755,'fdsfds',10,null,'d@sh.ff.com',0,0,10227622,'2019-01-02 14:38:27.358',0,'2019-01-03 19:53:00' from dual WHERE NOT EXISTS (SELECT * FROM MRBS_SCHEDULE ms where ms.START_TIME<'2019-01-03 19:53:00' and ms.END_TIME>'2019-01-03 19:53:00' and ms.ROOM_ID=10113558)
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 55 page no 228 n bits 872 index IND_MRBS_SCHEDULE_END_TIME of table `meeting`.`mrbs_schedule` trx id 24004 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 24005, ACTIVE 0 sec inserting
mysql tables in use 2, locked 2
5 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 2
MySQL thread id 11940, OS thread handle 123145557155840, query id 418448 localhost 127.0.0.1 username executing
INSERT INTO MRBS_SCHEDULE (ID,START_TIME,END_TIME,ROOM_ID,CREATE_BY,PRESIDE,REPEAT_ID,DESCRIPTION,NUM,TITLE,PRESIDE_EMAIL,PROJECTOR,CONFERENCE_CALL,CREATE_ID,BOOK_TIME,END_TYPE,EXPECTED_END_TIME) select null,'2019-01-03 19:54:00','2019-01-03 19:54:00',10113685,'z','z',12245756,'fdsfds',10,null,'z@sz.ff.com',0,0,10227544,'2019-01-02 14:38:27.397',0,'2019-01-03 19:54:00' from dual WHERE NOT EXISTS (SELECT * FROM MRBS_SCHEDULE ms where ms.START_TIME<'2019-01-03 19:54:00' and ms.END_TIME>'2019-01-03 19:54:00' and ms.ROOM_ID=10113685)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 55 page no 228 n bits 872 index IND_MRBS_SCHEDULE_END_TIME of table `meeting`.`mrbs_schedule` trx id 24005 lock mode S
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 55 page no 228 n bits 872 index IND_MRBS_SCHEDULE_END_TIME of table `meeting`.`mrbs_schedule` trx id 24005 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)

Редактировать: Таблица MRBS_SCHEDULE использование первичного ключа Auto_increment

Answer 1

тупик может возникнуть в любое время, и это нормальное поведение.Это происходит, когда транзакция 1 пытается обновить Таблицу B с использованием Таблицы A, но в то же время Транзакция 2 пытается обновить Таблицу A с использованием Таблицы B.

В основном Транзакции держатся самостоятельно, и поскольку никто не хочет сдаваться, возникает тупик.

вы можете установить порог взаимоблокировки для вашей базы данных, используя innodb_lock_wait_timeout

---

Из документации

Когда обнаружение взаимоблокировки включено (по умолчанию),InnoDB автоматически обнаруживает взаимоблокировки транзакций и откатывает транзакцию или транзакции для ее устранения.InnoDB пытается выбрать небольшие транзакции для отката, где размер транзакции определяется количеством вставленных, обновленных или удаленных строк.

InnoDB знает о блокировках таблицы, если innodb_table_locks = 1 (по умолчанию)и autocommit = 0, а уровень MySQL над ним знает о блокировках на уровне строк.В противном случае InnoDB не сможет обнаружить взаимоблокировки, в которых задействована блокировка таблицы, установленная инструкцией MySQL LOCK TABLES, или блокировка, установленная механизмом хранения, отличным от InnoDB.Устраните эти ситуации, установив значение системной переменной innodb_lock_wait_timeout.

Ссылка: https://dev.mysql.com/doc/refman/8.0/en/innodb-deadlock-detection.html