MySQL: ошибка 1213 Deadlock found при одновременном обновлении строк

#Что означает неисправность и в каких условиях возникает

Ошибка ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction появляется, когда две транзакции захватывают блокировки в разном порядке. Здесь разобран именно конфликт конкурентных UPDATE в InnoDB, а не любой сбой SQL. InnoDB выбирает одну транзакцию жертвой и откатывает её; приложение должно повторить всю транзакцию с ограниченным числом попыток, а порядок доступа к строкам следует сделать согласованным.

#Возможные причины: как различить

#Пошаговая диагностика и устранение

1. Сохраните полный код ошибкиВ журнале сайта найдите ERROR 1213 и время, идентификатор операции, имя таблицы; проверьте, что используется InnoDB и ошибка именно 1213, а не 1205 Lock wait timeout. Не публикуйте значения запросов, содержащие персональные данные или пароли; для воспроизведения создайте синтетические записи.
2. Откройте две независимые сессии для примераНа тестовой базе откройте два терминала и в каждом запустите mysql -u test_user -p -h 127.0.0.1 test_db, подставив реальные тестовые учётные данные. В первой консоли выполните BEGIN и обновите запись с ID 1, во второй BEGIN и запись ID 2, затем наоборот; одна из операций будет ждать, а после второго конкурирующего UPDATE возможно возникновение 1213. Не повторяйте этот эксперимент на рабочей таблице.
3. Прочитайте отчёт InnoDB о последнем конфликтеПод административным SQL-доступом выполните SHOW ENGINE INNODB STATUS\G в клиенте mysql: символ \G выводит вертикальный отчёт. Найдите раздел LATEST DETECTED DEADLOCK с операциями, таблицами, индексами и выбранной жертвой; он хранит только последний конфликт и может быть перезаписан новым событием. Скопируйте фрагмент без личных данных в служебный журнал.
4. Сопоставьте порядок запросов в кодеОткройте сервисный обработчик, где начинается транзакция; найдите BEGIN, UPDATE и COMMIT/ROLLBACK. Составьте порядок блокировки строк в двух конкурирующих запросах. Если один обновляет id=1 затем id=2, а второй наоборот, согласуйте порядок по возрастанию id; при нескольких таблицах также придерживайтесь одинаковой очередности.
5. Уменьшите срок удержания блокировокВынесите из транзакции длительные сетевые обращения, отправку почты и генерацию отчётов. Не удаляйте проверки целостности, не делайте многократный COMMIT ради исчезновения ошибки. Если транзакция должна быть атомарной, сокращайте время внутри BEGIN–COMMIT, сохраняя все необходимые проверки и изменения вместе.
6. Добавьте правильный повтор всей транзакцииПосле 1213 выполните ROLLBACK, если ещё требуется, откройте новую транзакцию и повторите последовательность операций целиком, предварительно заново прочитав изменившиеся данные. Ограничьте число попыток, делайте небольшую случайную задержку и не повторяйте внешнее действие вроде списания денег без защиты от повторного выполнения. Повтор одного UPDATE вместо всей операции часто некорректен.
7. Проверьте план запросов и индексНа тестовой копии для SELECT с тем же WHERE выполните EXPLAIN; убедитесь, что условие поиска использует ожидаемый индекс и не читает большинство строк. Добавление индекса делайте после проверки плана и стоимости изменения структуры, с резервной копией. Без проверки не ставьте FORCE INDEX и не отключайте обнаружение взаимных блокировок.
8. Повторите безопасный конкурентный тестНа тестовых строках одновременно выполните два запросa в обратном порядке после правки, убедитесь, что оба заканчиваются либо один корректно повторяется. Просмотрите журнал исключений: после ограниченного повтора нет необработанных 1213, данные согласованы и ни один заказ не применён дважды. Если конфликт остаётся, запишите новую пару транзакций из отчёта InnoDB и пересмотрите структуру операций.
9. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
   Выберите подходящий вариант — это не команды для последовательного выполнения

   Вариант 1Вводится в интерактивном mysql.

   SQLКомандаКопировать всёВыделить

   Вводится в интерактивном mysql. Требуется соответствующий доступ к диагностике InnoDB.

   SHOW ENGINE INNODB STATUS\G

   Вариант 2Только иллюстрация порядка на специально созданных тестовых данных; в другом сеансе обратный порядок может …

   SQLКопировать всёВыделить

   Только иллюстрация порядка на специально созданных тестовых данных; в другом сеансе обратный порядок может создать deadlock. Не выполнять на настоящей таблице.

   START TRANSACTION;
   UPDATE demo_items SET value = value + 1 WHERE id = 1;
   UPDATE demo_items SET value = value + 1 WHERE id = 2;
   COMMIT;

#Как проверить исправление и что делать, если оно не помогло

Проверяйте не только отсутствие сообщений 1213, но и правильные итоговые значения, соответствие количества списаний/операций и журналы повторных попыток. Если проблема появляется только под нагрузкой, соберите тексты обеих транзакций и планы EXPLAIN без персональных данных; воспроизводите на копии.