Скорость
MySQL Lock wait timeout: заказы ждут блокировку
MySQL сообщает Lock wait timeout, а заказы зависают. Объясняем, кто кого ждёт и почему увеличение времени ожидания не всегда помогает.
Что происходит и с чего начать
База может временно блокировать изменяемые данные, чтобы одновременные операции не испортили результат друг друга. Если другая операция держит нужные записи слишком долго, следующий запрос ждёт и может получить тайм-аут блокировки. Это отличается от медленного поиска данных. Поэтому сначала нужно найти не только ожидающий запрос, но и тот, который удерживает блокировку. Увеличение лимита ожидания способно скрыть сообщение, оставив покупателю ещё более долгую паузу при оформлении.
Что можно проверить самостоятельно
- Запишите время отказа и действие пользователя. Уточните, совпадает ли оно с обменом, массовым редактированием товаров или другим длительным процессом записи в базу.
- Проверьте состояние заказа после ошибки: часть внешних действий могла произойти до отказа сохранения. Не просите клиента сразу повторить оплату или всю покупку без сверки результата.
- Сохраните сведения о периодичности и затронутых товарах. Не завершайте случайные процессы базы через панель: сначала нужно понимать, какие операции и данные они обслуживают.
Как понять результаты проверки
Специалист находит цепочку ожидания и границы транзакций. Проверяются порядок изменения записей, длительность работы и запросы, захватывающие больше данных, чем нужно. Иногда помогает разделение массовой операции на разумные части, иногда — изменение логики конкретной транзакции. Но выбор зависит от требуемой целостности данных: нельзя ускорять заказ ценой частичного сохранения. Разработчик должен объяснить, почему выбранное изменение уменьшает конфликт и как приложение обрабатывает редкий повторный отказ, если полностью исключить ожидание невозможно.
Что проверяет разработчик
Для этой части понадобятся доступ к настройкам, журналам ошибок или коду. Её можно передать специалисту вместе с результатами предыдущих шагов.
- Снимите сведения об активных транзакциях и ожиданиях во время сбоя. Найдите блокирующую транзакцию и длительность её работы.
- Проверьте, не выполняется ли внешний API-вызов внутри транзакции. Пока приложение ждёт сеть, затронутые строки могут оставаться заблокированными.
- Сравните порядок обновления строк в параллельных сценариях. Отдельно различайте тайм-аут ожидания и взаимную блокировку.
На что обратить внимание
Долгая транзакция удерживает ресурсы дольше необходимого. Плохой индекс может расширять объём работы и блокировок, но причина подтверждается планом и состоянием транзакций.
Как исправляют причину
Сократите транзакцию до необходимых операций базы, выровняйте порядок захвата ресурсов и оптимизируйте поиск строк. Повторы выполняйте ограниченно и только с учётом идемпотентности всей операции.
Как убедиться, что проблема решена
Запустите конкурирующие тестовые заказы. Проверьте время ожидания, целостность состава и остатков, а также поведение при вынужденном откате транзакции.
Проверьте оформление одновременно с тем процессом, который вызывал конфликт, в согласованных тестовых условиях. Сверьте товары, суммы и остатки, а не только отсутствие сообщения об ошибке. Убедитесь, что повтор после временного отказа не создаёт лишний заказ. Приёмка должна подтвердить целостность данных и приемлемое ожидание при обычной конкурирующей работе магазина, а не одиночный запрос в пустой системе.