INSERT DELAYED ...
является специфической для MySQL
возможностью, которая очень полезна, если клиент не может ждать завершения
команды
. Такая проблема встречается часто - она возникает, когда
MySQL используется для ведения журналов (проще говоря, для логгинга) и при
этом периодически запускаются команды
, для выполнения
которых требуется много времени. Оператор
был введен в версию
MySQL 3.22.15. Он является расширением MySQL к ANSI SQL92.
. Следует
учитывать, что таблицы
, поэтому если нет свободных блоков в середине файла данных, то
необходимость в применении
возникает очень редко.
See section
.
клиент сразу же получает
успешный ответ от сервера, а запись будет добавлена в таблицу сразу же
после того, как эту таблицу перестанет использовать другой поток.
заключается в том, что данные от многих клиентов собираются вместе и
записываются одним блоком. Это намного быстрее, чем несколько отдельных
операций вставки.
Обратите внимание: в настоящее время все записи, поставленные в очередь на
добавление, хранятся только в памяти до тех пор, пока они не будут
записаны на диск. Отсюда следует, что если выполнение
) или программа умрет, то все находящиеся
в очереди данные, которые не записаны на диск, будут потеряны!.
Ниже детально описано, что происходит при использовании опции
. В этом описании ''поток'' понимается как
поток, принимающий команду
, а ''обработчик'' - это поток,
который обрабатывает все команды
в конкретной таблице.
в данной таблице,
если подобный обработчик уже не существует.
Данный поток проверяет, выполнил ли уже обработчик блокировку
;
если нет, то он предписывает обработчику сделать это. Блокировка
может быть осуществлена даже в случае, если блокировки
на данной таблице уже выполнены другими потоками. Однако
обработчик будет ожидать всех блокировок
, чтобы убедиться в том, что структура
таблицы соответствует последнему обновлению.
, но вместо записи строки в таблицу он
ставит финальную копию этой строки в очередь, управляемую
потоком-обработчиком. Поток отмечает все синтаксические ошибки и
сообщает о них клиентской программе.
для данной результирующей строки; он также не может
получить эти данные с сервера, поскольку команда
возвращает
результат до полного завершения операции вставки. По той же причине
ничего существенного не даст и использование функции C API
.
Обновление журнала обновлений производится потоком-обработчиком после
вставки строки в таблицу. В случае многострочной вставки обновление
журнала обновлений производится при записи первой строки.
строк, обработчик проверяет,
не находятся ли в ожидании выполнения какие-либо команды
. Если
да, то обработчик перед продолжением своей работы ''пропускает их
вперед'' на выполнение.
Если очередь обработчика больше не содержит строк, то с данной таблицы
будет снята блокировка. Если в течение
, то обработчик
завершит свою работу.
Если более, чем
строк уже ожидают в очереди
обработчика, то поток, запрашивающий
, будет ждать,
пока не освободится место в очереди. Таким образом можно иметь
уверенность в том, что
не займет всю память сервера для
хранения запросов данной очереди.
. Поток-обработчик можно
уничтожить запуском команды
. Однако перед своим завершением он вначале сохранит в
таблице все поставленные в очередь строки. В процессе сохранения он не
будет принимать никаких новых команд
от иного потока. При
выполнении после этого команды
будет создан новый
поток-обработчик. Обратите внимание: отсюда следует, что команды
имеют более высокий приоритет, чем обычные команды
, если уже существует запущенный обработчик
!
Другие команды обновления должны ожидать, пока не опустеет очередь
.
Чтобы увидеть эти переменные, следует вызвать команду
.
Обратите внимание: если данная таблица не используется, то команда
работает медленнее, чем обычная команда
. Кроме того,
возникает дополнительная нагрузка на сервер, поскольку требуется управлять
отдельным потоком для каждой таблицы, для которой используется
. Это означает, что команду
следует применять
только тогда, когда в ней есть реальная необходимость!