Как избежать mysql 'Deadlock найден при попытке получить блокировку; попробуйте перезапустить транзакцию

Тупик случается, когда две транзакции ожидают друг друга, чтобы получить блокировку. Пример:

• Tx 1: блокировка A, затем B
• Tx 2: заблокировать B, затем A

Существует множество вопросов и ответов о взаимоблокировках. Каждый раз, когда вы вставляете/обновляете/или удаляете строку, происходит блокировка. Чтобы избежать тупиковой ситуации, вы должны убедиться, что параллельные транзакции не обновляют строку в порядке, который может привести к тупиковой ситуации. Вообще говоря, попытайтесь получить блокировку всегда в том же порядке даже в разных транзакциях (например, всегда сначала таблицу A, затем таблицу B).

Другой причиной тупика в базе данных может быть отсутствующих индексов. Когда строка вставлена ​​/обновлена ​​/удалена, база данных должна проверять реляционные ограничения, то есть убедиться, что отношения согласованы. Для этого база данных должна проверять внешние ключи в связанных таблицах. Это может привести к приобретению другой блокировки, чем измененная строка. Убедитесь, что всегда есть индекс для внешних ключей (и, конечно, первичных ключей), иначе это может привести к блокировке таблицы вместо блокировки строк . Если происходит блокировка таблицы, конфликт блокировки выше и вероятность блокировки увеличивается.

Вполне вероятно, что оператор delete будет влиять на большую часть общих строк в таблице. В конечном итоге это может привести к блокировке таблицы при удалении. Удержание блокировки (в данном случае row- или блокировки страниц) и получение большего количества блокировок всегда является фактором взаимоблокировки. Однако я не могу объяснить, почему оператор insert приводит к эскалации блокировки - возможно, это связано с разбиением/добавлением страницы, но кто-то, кто знает MySQL, должен будет заполнить его.

Для начала можно попытаться явно получить блокировку таблицы сразу для инструкции delete. См. ЛОКАЛЬНЫЕ ТАБЛИЦЫ и проблемы с блокировкой таблиц.

Вы можете попробовать, чтобы это задание на delete работало, сначала вставив ключ каждой строки, которая будет удалена в временную таблицу, такую как псевдокод

create temporary table deletetemp (userid int);

insert into deletetemp (userid)
  select userid from onlineusers where datetime <= now - interval 900 second;

delete from onlineusers where userid in (select userid from deletetemp);

Прерывание этого, как это, менее эффективно, но это позволяет избежать блокировки ключа при delete.

Кроме того, измените ваши запросы select чтобы добавить предложение where, исключая строки старше 900 секунд. Это позволяет избежать зависимости от задания cron и позволяет перенастроить его на работу менее часто.

Теория о взаимоблокировках: у меня нет большого фона в MySQL, но здесь идет... delete будет содержать блокировку ключевого диапазона для datetime, чтобы предотвратить соответствие строк, where предложение where добавлено в середине транзакция, и поскольку она находит строки для удаления, она попытается получить блокировку на каждой странице, которую она модифицирует. insert собирается получить блокировку на странице, в которую она вставляется, а затем попытаться получить блокировку ключа. Обычно insert будет терпеливо ждать, пока эта блокировка клавиатуры не откроется, но это затормозит, если delete попытается заблокировать ту же страницу, которую использует insert потому что для delete требуется эта блокировка страницы, а insert нуждается в блокировке ключа. Это не похоже на вставки, но delete и insert используют диапазоны datetime, которые не перекрываются, поэтому, возможно, что-то еще происходит.

http://dev.mysql.com/doc/refman/5.1/en/innodb-next-key-locking.html

Для программистов на Java, использующих Spring, я избежал этой проблемы, используя аспект AOP, который автоматически повторяет транзакции, которые запускаются в переходные тупики.

См. @RetryTransaction Javadoc для получения дополнительной информации.

У меня есть метод, внутренности которого завернуты в MySqlTransaction.

Вопрос о тупике появился для меня, когда я запускал тот же метод параллельно с собой.

Не было проблемы с запуском одного экземпляра метода.

Когда я удалил MySqlTransaction, я смог запустить этот метод параллельно с собой без проблем.

Просто поделившись своим опытом, я ничего не пропагандирую.