Определения событий сохранены в таблице mysql.event, которая была добавлена в MySQL 5.1.6. Чтобы удвлить событие, созданное другим пользователем, MySQL-пользователь root (или другой пользователь с необходимыми привилегиями) может удалять строки из этой таблицы. Например, чтобы удалить событие e_insert, показанное выше, root может использовать следующую инструкцию:
DELETE FROM mysql.event
WHERE db = 'myschema' AND
definer = 'jon@ghidora' AND name = 'e_insert';
Очень важно соответствовать имени события, имени схемы базы данных и логину пользователя при удалении строк из таблицы mysql.event. Это потому, что тот же самый пользователь может создавать различные события с тем же самым именем в различных схемах.
Обратите внимание: пространство имен для планируемых событий изменено в MySQL 5.1.12. До этого MySQL различные пользователи могли создавать различные события, имеющие то же самое имя в той же самой базе данных, в MySQL 5.1.12 и позже это не так. При обновлении на MySQL 5.1.12 или позже с MySQL 5.1.11 или ранее до выполнения обновления чрезвычайно важно удостовериться, что никакие события в той же самой базе данных не используют совместно то же самое имя.
Привилегии EVENT пользователей сохранены в столбцах Event_priv таблиц mysql.user и mysql.db. В обоих случаях этот столбец хранит одно из значений 'Y' или 'N' (по умолчанию 'N'). mysql.user.Event_priv установлен в 'Y' для данного пользователя только, если этот пользователь имеет глобальную привилегию EVENT (то есть, если привилегия была подарена, используя GRANT EVENT ON *.*). Для привилегии EVENT уровня схемы GRANT создает строку в mysql.db и устанавливает столбец Db той строки к имени схемы, столбец User к имени пользователя и Event_priv столбца в 'Y'. Никогда не должно быть никакой потребности управлять этими таблицами непосредственно, так как GRANT EVENT и инструкция REVOKE EVENT выполняют требуемые операции на них.
MySQL 5.1.6 представляет пять переменных состояния, обеспечивающих подсчет связанных с событием операций (но не инструкций, выполненных событиями). Они:
Com_create_event: число инструкций CREATE EVENT, выполненных начиная с последнего рестарта сервера.
Com_alter_event: число инструкций ALTER EVENT, выполненных начиная с последнего рестарта сервера.
Com_drop_event: число инструкций DROP EVENT, выполненных начиная с последнего рестарта сервера.
Com_show_create_event: число инструкций SHOW CREATE EVENT, выполненных начиная с последнего рестарта сервера.
Com_show_events: число инструкций SHOW EVENTS, выполненных начиная с последнего рестарта сервера.
Вы можете просматривать текущие значения для все них в одно время, выполняя инструкцию SHOW STATUS LIKE '%event%';.
8.6. Ограничения планировщика событий
Этот раздел вносит в список ограничения планирования событий в MySQL.
В MySQL любая таблица, вызванная в инструкции действия события должна быть полностью квалифицирована именем схемы, в которой это происходит (то есть, как schema_name.table_name ).
Событие не может быть создано, изменено или удалено триггером, сохраненной подпрограммой или другим событием. Событие также не может создавать, изменять или удалять триггеры или сохраненные подпрограммы (Глюк #16409 и Глюк #18896).
Синхронизации события, использующие интервалы YEAR, QUARTER, MONTH и YEAR_MONTH отсчитываются в месяцах, любой другой интервал отсчитывается в секундах. Не имеется никакого способа заставить планируемые события, происходящие в тот же самый момент, выполниться в заданном порядке. Кроме того, из-за округления, характера прикладных программ и того факта, что ненулевой отрезок времени требуется, чтобы создать событие и сообщить о выполнении, события могут быть отсрочены на целых 1 или 2 секунды. Однако, время, показанное в столбце LAST_EXECUTED таблицы INFORMATION_SCHEMA.EVENTS или столбце last_executed таблицы mysql.event является всегда точным до секунды относительно момента, когда событие было фактически выполнено (Глюк #16522).
Выполнение инструкций события не воздействует на серверные счетчики, вроде Com_select и Com_insert, которые отображаются командой SHOW STATUS.
До MySQL 5.1.12 Вы не могли просматривать события другого пользователя в таблице INFORMATION_SCHEMA.EVENTS. Другими словами, любой запрос, сделанный к этой таблицы обрабатывался, как если бы содержал DEFINER = CURRENT_USER() в предложении WHERE.
События не могут быть созданы с временем старта, которое находится в прошлом.
События не поддерживают времена позже, чем конец Unix Epoch, это приблизительно конец 2037 года. До MySQL 5.1.8 обработка в планируемых событиях дат позже чем, эта вызывала сбой, теперь такие даты специально отвергнуты планировщиком событий (Глюк #16396).