Есть 3 таблицы, у каждой из них стоят триггеры, которые изменяют четвертую. Возникает ситуация, когда триггеры одной из первых трех таблиц блокируют возможность записи для остальных. Возникает lockwait timeout, который откатывает запись. В итоге в исходных таблицах запись есть, а в четвертой данные не изменились.

Вопросы:
1. Можно ли в триггере игнорировать лок? Обновляются разные поля. По сути - четвертая таблица - сборная для первых трех.
2. Можно ли сделать отложенное обновление или вставку, чтобы данные гарантировано попали в базу?

miksoftНа каком движке все эти таблицы?
innodb (на самом деле не совсем - используется percona).

Спасибо за информацию.

alex564657498765453чтото тут не так.

таймаут я думаю больше чем время лока в раз 10 так точно...поэтому как одна может залочить так долго??? разве что она очень не оптимально чтото делает.


Вообще - данные пишутся быстро, но их много.

alex564657498765453вообще стандартный подход для обхода подобного, это как ты верно подметил отложенные действия...

принцип.
тригер должен обновить field1 в table1 для записи с id=@num

делаем таблицу типа мемори, где два столбика - айди и новое значение поля.

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

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

=======
оптимизировать можно как хочешь....
======


Расписание, в силу некоторых причин, использовать не получится. Если-бы можно было - то я на расписание поставил бы обновление - так больше контроля - я бы просто последовательно в запросе обновлял данные из трех таблиц - вначале первой, потом - второй и затем - третьей. Я имел ввиду - может есть какие ключи запроса, чтобы нативно поставить запрос в очередь?

alex564657498765453========
если использовать тебе тригер бифо, то если он не выполниться, то и само действие поидее не должно произойти.

Этот вариант тоже не совсем прокатит - данные посылаются пачками (относительно большими). Если хотя-бы один запрос не выполнен, то пачка снова отправляется - и так, пока не запишется без ошибок. В итоге накапливается много задач.

Вобщем - спасибо, буду дальше думать.