The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Базы данных, SQL" / Оглавление документа
Глава 8. Планировщик событий

Эта глава описывает планировщик событий MySQL, поддержка которого была добавлена в MySQL 5.1.6.

8.1. Обзор планировщика событий

События MySQL представляют собой задачи, которые выполняются согласно плану. Следовательно, мы иногда обращаемся к ним как к планируемым событиям. Когда Вы создаете событие, Вы создаете именованный объект базы данных, содержащий одну или большее количество инструкций SQL, которые будут выполнены в одном или более регулярных интервалах, начиная и заканчивая в специфическую дату и время. Концептуально, это подобно идее Unix crontab (также известно как cron job) или Windows Task Scheduler.

Регламентная работа этого типа также иногда известна как временный триггер, подразумевая, что она является объектом, который вызван приходом времени. В то время, как это по существу правильно, мы предпочитаем использовать термин "события", чтобы избежать беспорядка с понятием триггера.

В то время как не имеется никакого средства в стандарте SQL для планирования события, есть прецеденты в других системах баз данных, и Вы можете обратить внимание на некоторые подобия между этими реализациями.

События MySQL имеют следующие главные свойства и реквизиты:

События выполнены специальным потоком планировщика событий. При выполнении поток планировщика события и текущее состояние могут быть замечены пользователями, имеющими привилегию SUPER в выводе SHOW PROCESSLIST, как показано ниже.

Глобальная переменная event_scheduler определяет, включен ли планировщику событий на сервере. При запуске MySQL 5.1.12 это имеет одно из этих 3 значений, которые воздействуют на планируемые события, как описано здесь:

Когда сервер запущен, event_scheduler может переключаться ON и OFF (используя SET). Также возможно использовать 0 для OFF и 1 для ON при установке этой переменной. Таким образом, любая из следующих 4 инструкций может использоваться в клиенте mysql, чтобы включить планировщик событий:

SET GLOBAL event_scheduler = ON;
SET @@global.event_scheduler = ON;
SET GLOBAL event_scheduler = 1;
SET @@global.event_scheduler = 1;

Точно так же любая из этих 4 инструкций может использоваться, чтобы выключить планировщик событий:

SET GLOBAL event_scheduler = OFF;
SET @@global.event_scheduler = OFF;
SET GLOBAL event_scheduler = 0;
SET @@global.event_scheduler = 0;

Хотя ON и OFF имеет числовые эквиваленты, значение, отображаемое для event_scheduler вызовом SELECT или SHOW VARIABLES всегда OFF, ON или DISABLED. Значение DISABLED не имеет никакого числового эквивалента. По этой причине ON и OFF обычно предпочитаются 1 и 0 при установке этой переменной.

Обратите внимание, что делая попытку устанавливать event_scheduler без того, чтобы определять ее как глобальную переменную, вы получите ошибку:

mysql< SET @@event_scheduler = OFF;
ERROR 1229 (HY000): Variable 'event_scheduler' is a
GLOBAL variable and should be set with SET GLOBAL

Важно: нельзя включать или выключать планировщик, если сервер работает. То есть, Вы можете изменять значение event_scheduler на DISABLED или с DISABLED на одно из других разрешенных значений для этой опции только, когда сервер остановлен. Попытка это сделать, когда он выполняется, вызовет сбой с ошибкой.

Чтобы отключить планировщик событий, используйте один из следующих двух методов:

Чтобы включить планировщик, перезапустите сервер без параметра --event-scheduler=DISABLED или после удаления (или комментирования) строки, содержащей event_scheduler=DISABLED в файле конфигурации. В качестве альтернативы Вы можете использовать ON (или 1), либо OFF (или 0) вместо значения DISABLED при старте сервера.

Обратите внимание: Вы можете выдавать инструкции манипулирования событиями, когда event_scheduler установлен в DISABLED. Никакие предупреждения или ошибки не будут сгенерированы в таких случаях (если инструкции самостоятельно допустимы). Однако, планируемые события не могут выполняться, пока эта переменная не установлена в ON (или 1). Как только это было выполнено, поток планировщика выполняет все события, чьи планирующие условия удовлетворены.

В MySQL 5.1.11 event_scheduler вела себя следующим образом: эта переменная могла брать одно из значений 0 (или OFF), 1 (или ON) или 2. Установка в 0 отключала планировщик. Установка в 1 запускала планировщик и выполняла планируемые события. В этом состоянии поток планировщика события, казалось, бездействовала когда просматривалась с SHOW PROCESSLIST. Когда event_scheduler была установлена в 2 (что и было значением по умолчанию), планировщик событий был приостановлен: поток планировщика событий выполнялся и мог быть найден в выводе SHOW PROCESSLIST (где в столбце State отображалось Suspended), но не выполнялись никакие планируемые события. Значение event_scheduler могло быть изменено только между 1 (или ON) и 2 во время работы сервера. Установка в OFF или изменение из OFF) требовала рестарта сервера.

До MySQL 5.1.11 event_scheduler мог брать только одно из 2 значений: 0|OFF (по умолчанию) или 1|ON без перезапуска сервера.

MySQL 5.1.6 и позже обеспечивает таблицу EVENTS в базе данных INFORMATION_SCHEMA. Эта таблица может делать запрос к информации относительно планируемых событий, которые были определены на сервере.

8.2. Синтаксис планировщика событий

MySQL 5.1.6 и позже обеспечивает несколько инструкций SQL для работы с планируемыми событиями:

8.2.1. Синтаксис CREATE EVENT 

CREATE EVENT [IF NOT EXISTS] event_name
       ON SCHEDULE schedule
       [ON COMPLETION [NOT] PRESERVE] [ENABLE | DISABLE]
       [COMMENT 'comment']
       DO sql_statement;

schedule:
AT timestamp [+ INTERVAL interval]
| EVERY interval [STARTS timestamp]
[ENDS timestamp]

interval:
quantity {YEAR | QUARTER | MONTH | DAY | HOUR |
                       MINUTE | WEEK | SECOND | YEAR_MONTH | DAY_HOUR |
                       DAY_MINUTE | DAY_SECOND | HOUR_MINUTE | HOUR_SECOND |
                       MINUTE_SECOND}

Эта инструкция создает и планирует новое событие. Минимальные требования для допустимой инструкции CREATE EVENT следующие:

Это пример минимальной инструкции

CREATE EVENT myevent
       ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 1 HOUR
       DO UPDATE myschema.mytable SET mycol = mycol + 1;

Предыдущая инструкция создает событие myevent. Это событие выполняется один раз в час после создания, выполняя инструкцию SQL, которая увеличивает значение столбца mycol таблицы myschema.mytable на 1.

Имя event_name должно быть допустимым идентификатором MySQL с максимальной длиной в 64 символа. Это может быть разграничено, используя обратные импульсы сигнала времени, и может быть квалифицировано с именем схемы базы данных. Событие связано с пользователем MySQL (definer) и схемой, так что имя должно быть уникальным среди имен событий внутри этой схемы. Вообще, правила, управляющие именами событий, такие же, как для имен сохраненных подпрограмм, поскольку события по сути и являются такими подпрограммами, только особыми.

Если никакая схема не обозначена как часть event_name, то принята заданная по умолчанию схема. Definer всегда текущий пользователь MySQL.

До MySQL 5.1.12 было возможно для двух различных пользователей создать различные события, имеющие то же самое имя в той же самой схеме базы данных.

Обратите внимание: MySQL использует сравнения без учета регистра при прверке уникальности имен события. Это означает, что, например, Вы не можете иметь два события events named myevent и MyEvent в той же самой схеме базы данных.

Функция IF NOT EXISTS с инструкцией CREATE EVENT работает полностью аналогично варианту с CREATE TABLE: если событие event_name уже существует в той же самой схеме, никаких действий не предпринимается, и никакой ошибки не будет. Однако, предупреждение будет сгенерировано.

Предложение ON SCHEDULE определяет, когда, как часто и как долго sql_statement определено для повторения события. Это предложение берет одну из двух форм:

Предложение ON SCHEDULE может использовать выражения, включающие встроенные функции MySQL и переменные пользователя, чтобы получить любое значение timestamp или interval. Вы не можете использовать сохраненные подпрограммы или определяемые пользователем функции в таких выражениях, и при этом Вы не можете использовать любые ссылки на таблицы, однако, Вы можете SELECT FROM DUAL. Это истинно для инструкций CREATE EVENT и ALTER EVENT. Начиная с MySQL 5.1.13, ссылки на сохраненные подпрограммы, определяемые пользователем функции и таблицы в таких случаях специально отвергнуты и вызывают сбой с ошибкой (Глюк #22830).

Обычно, как только событие истекло, оно немедленно уничтожается. Вы можете отменять это поведение, определяя ON COMPLETION PRESERVE. Использование ON COMPLETION NOT PRESERVE просто делает заданное по умолчанию поведение явным.

Вы можете создавать событие и сохранить его неактивным для дальнейшего неспешного потребления, используя ключевое слово DISABLE. В качестве альтернативы Вы можете использовать ENABLE, чтобы сделать явным заданное по умолчанию состояние, которое является активным. Это наиболее полезно вместе с ALTER EVENT.

Вы можете обеспечивать комментарий для события, используя предложение COMMENT. Здесь comment может быть любой строкой до 64 символов, которые Вы желаете использовать для описания события. Текст комментария, являющийся строковым литералом, должен быть окружен кавычками.

Предложение DO определяет действие, которое несет событие, и состоит из инструкции SQL. Почти любая допустимая инструкция MySQL, которая может использоваться в сохраненной подпрограмме, может также использоваться как инструкция действия для планируемого события. Например, следующее событие e_hourly удаляет все строки из таблицы sessions раз в час, если только эта таблица часть схемы site_activity: 

CREATE EVENT e_hourly ON SCHEDULE
       EVERY 1 HOUR COMMENT 'Clears out sessions table each hour.'
       DO DELETE FROM site_activity.sessions;

Инструкция CREATE EVENT, которая содержит инструкцию ALTER EVENT в предложении DO, появляется, однако, когда сервер пытается выполнить возникающее в результате планируемое событие, получается сбой выполнения с ошибкой.

Обратите внимание: инструкции SHOW и SELECT, которые просто возвращают набор результатов, не имеют никакого эффекта, когда используются в событии, вывод из них не будет послан MySQL Monitor. Однако, Вы можете использовать инструкции типа SELECT INTO и INSERT ... SELECT, которые сохраняют результат.

Любая ссылка в предложении DO к таблице в другой схеме базы данных должна быть квалифицирована с именем схемы, в которой таблица находится. В MySQL 5.1.6 все таблицы, вызванные в предложениях DO событий должны были включать ссылку на базу данных.

Как и в случае с сохраненными подпрограммами, Вы можете использовать много инструкций в предложении DO заключением их в слова BEGIN и END, как показано здесь:

DELIMITER |
CREATE EVENT e_daily ON SCHEDULE
       EVERY 1 DAY
       COMMENT 'Saves total number of sessions then clears the table each day.'
       DO BEGIN
   INSERT INTO site_activity.totals (when, total)
   SELECT CURRENT_TIMESTAMP, COUNT(*)
   FROM site_activity.sessions;
   DELETE FROM site_activity.sessions;
END |
DELIMITER ;

Обратите внимание на использование инструкции DELIMITER, чтобы изменить операторный разделитель, как с сохраненными подпрограммами.

Более сложные составные инструкции, типа тех, что используюся в сохраненных подпрограммах, возможны в событии. Этот пример использует локальные переменные, драйвер ошибки и конструкцию управления потоком данных: 

DELIMITER |
CREATE EVENT e ON SCHEDULE
       EVERY 5 SECOND DO BEGIN
   DECLARE v INTEGER;
   DECLARE CONTINUE HANDLER FOR SQLEXCEPTION BEGIN END;
   SET v = 0;
   WHILE v < 5 DO
     INSERT INTO t1 VALUES (0);
     UPDATE t2 SET s1 = s1 + 1;
     SET v = v + 1;
   END WHILE;
END |
DELIMITER ;

Не имеется никакого способа передать параметры непосредственно событию, однако, возможно вызвать сохраненную подпрограмму с параметрами:

CREATE EVENT e_call_myproc ON SCHEDULE
       AT CURRENT_TIMESTAMP + 1 DAY
       DO CALL myproc(5, 27);

Кроме того, если definer события имеет привилегию SUPER, то событие может читать и записывать глобальные переменные. Так как предоставление этой привилегии влечет за собой потенциал для неправильного обращения, критическая осторожность должна быть проявлена.

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

8.2.2. Синтаксис ALTER EVENT

ALTER EVENT event_name
      [ON SCHEDULE schedule]
      [RENAME TO new_event_name]
      [ON COMPLETION [NOT] PRESERVE] [ENABLE | DISABLE]
      [COMMENT 'comment']
      [DO sql_statement]

Инструкция ALTER EVENT используется, чтобы изменить одну или большее количество характеристик существующего события. Синтаксис для каждого из предложений ON SCHEDULE, ON COMPLETION, COMMENT, ENABLE / DISABLE и DO точно такой же, как когда они используются с CREATE EVENT.

Начиная с MySQL 5.1.12, любой пользователь может изменять событие, определенное в базе данных, для которой этот пользователь имеет привилегию EVENT. Когда пользователь выполняет успешную инструкцию ALTER EVENT он становится definer для произведенного события.

В MySQL 5.1.11 и ранее событие могло быть изменено только definer или пользователем, имеющим привилегию SUPER. ALTER EVENT работает только с существующим событием:

mysql> ALTER EVENT no_such_event
     >       ON SCHEDULE
     >       EVERY '2:3' DAY_HOUR;
ERROR 1517 (HY000): Unknown event
'no_such_event'

В каждом из следующих примеров считайте, что событие myevent определено, как показано здесь:

CREATE EVENT myevent ON SCHEDULE
       EVERY 6 HOUR COMMENT 'A sample comment.'
       DO UPDATE myschema.mytable SET mycol = mycol + 1;

Следующая инструкция изменяет план для myevent с одного раза каждые шесть часов (запуск немедленно) на один раз каждые двенадцать часов, запуская четыре часа со времени выполнения инструкции:

ALTER EVENT myevent ON SCHEDULE
      EVERY 12 HOUR STARTS
      CURRENT_TIMESTAMP + 4 HOUR;

Чтобы отключить myevent используйте эту инструкцию ALTER EVENT:

ALTER EVENT myevent DISABLE;

Предложение ON SCHEDULE может использовать выражения, включающие встроенные функции MySQL и переменные пользователя, чтобы получить любой timestamp или interval. Вы не можете использовать сохраненные подпрограммы или определяемые пользователем функции в таких выражениях, и при этом Вы не можете использовать любые ссылки на таблицы, однако, Вы можете использовать SELECT FROM DUAL.

Инструкция ALTER EVENT, которая содержит другую инструкцию ALTER EVENT в предложении DO, допустима. Однако, когда сервер пытается выполнять возникающее в результате планируемое событие, произойдет сбой с ошибкой.

Возможно изменить много характеристик события в одиночной инструкции. Этот пример изменяет инструкцию SQL, выполненную myevent, а также план для события:

ALTER TABLE myevent ON SCHEDULE
      AT CURRENT_TIMESTAMP + INTERVAL 1 DAY
      DO TRUNCATE TABLE myschema.mytable;

Чтобы переименовывать событие, используйте предложение RENAME TO инструкции ALTER EVENT, как показано здесь:

ALTER EVENT myevent RENAME TO yourevent;

Предыдущая инструкция переименовывает событие myevent в yourevent. Примечание : не имеется никакой инструкции RENAME EVENT.

Вы можете также переместить событие в другую схему, используя ALTER EVENT ... RENAME TO ... и запись в формате schema_name.table_name, как показано здесь:

ALTER EVENT oldschema.myevent RENAME TO newschema.myevent;

Чтобы выполнять предыдущую инструкцию, пользователь, выполняющий это, должен иметь привилегию EVENT на схемах oldschema и newschema базы данных.

Необходимо включить только те параметры в инструкцию ALTER EVENT, которые соответствуют характеристикам, которые Вы фактически желаете изменить, параметры, которые опущены, сохраняют их существующие значения. Это включает любые значения по умолчанию для CREATE EVENT, например, ENABLE.

8.2.3. Синтаксис DROP EVENT

DROP EVENT [IF EXISTS] event_name

Эта инструкция удаляет событие event_name. Событие немедленно прекращает активность и будет удалено полностью с сервера.

Если событие не существует, произойдет ошибка ERROR 1517 (HY000): Unknown event 'event_name'. Вы можете поменять это и заставить инструкцию провалиться тихо, используя опцию IF EXISTS.

Начиная с MySQL 5.1.12, событие может быть удалено любым пользователем, имеющим привилегию EVENT на схеме базы данных, событие в которой должно быть удалено. В MySQL 5.1.11 и ранее событие могло быть удалено только definer или пользователем, имеющим привилегию SUPER.

8.3. Метаданные события

Информация относительно событий может быть получена следующим образом:

8.4. Состояние планировщика событий

Информация относительно состояния планировщика события для отладки и целей поиска неисправностей может быть получена следующим образом:

8.5. Планировщик событий и привилегии MySQL

Чтобы включить или отключить выполнение планируемых событий, необходимо установить значение глобальной переменной event_scheduler. Это требует привилегии SUPER.

MySQL 5.1.6 представляет привилегию EVENT, управляя созданием, модификацией и стиранием событий. Эта привилегия может быть подарена, используя GRANT. Например, эта инструкция GRANT предоставляет привилегию EVENT для схемы myschema на пользователя jon@ghidora:

GRANT EVENT ON myschema.* TO jon@ghidora;

Чтобы предоставлять этому пользователю привилегию EVENT на всех схемах, требуется следующая инструкция:

GRANT EVENT ON *.* TO jon@ghidora;

Привилегия EVENT имеет контекст уровня схемы. Следовательно, попытка предоставлять ее на одиночной таблице приводит к ошибке, как показано здесь:

mysql> GRANT EVENT ON myschema.mytable TO jon@ghidora;
ERROR 1144 (42000): Illegal GRANT/REVOKE command;
please consult the manual to see which privileges can be used

Важно понять, что событие выполнено с привилегиями definer, и что оно не может выполнять любые действия, для которых definer не имеет необходимых привилегий. Например, предположим, что jon@ghidora имеет привилегию EVENT для myschema. Предположим также, что этот пользователь имеет привилегию SELECT для myschema, но никаких других привилегий для этой схемы он не имеет. Возможно для jon@ghidora создать новое событие типа этого:

CREATE EVENT e_store_ts ON SCHEDULE
       EVERY 10 SECOND DO
       INSERT INTO myschema.mytable VALUES (UNIX_TIMESTAMP());

Пользователь ждет в течение минуты или более, а затем выполняет запрос SELECT * FROM mytable;, ожидая, что увидит несколько новых строк в таблице. Вместо этого он находит, что таблица пуста: так как он не имеет привилегии INSERT для рассматриваемой таблицы, событие не имеет никакого эффекта.

Если Вы осматриваете файл регистрации ошибок MySQL (hostname.err), Вы можете видеть, что событие-то выполняется, но действие это вызывает сбой, как обозначено RetCode=0:

060209 22:39:44 [Note] EVEX EXECUTING event newdb.e [EXPR:10]
060209 22:39:44 [Note] EVEX EXECUTED event newdb.e[EXPR:10]. RetCode=0
060209 22:39:54 [Note] EVEX EXECUTING event newdb.e [EXPR:10]
060209 22:39:54 [Note] EVEX EXECUTED event newdb.e[EXPR:10]. RetCode=0
060209 22:40:04 [Note] EVEX EXECUTING event newdb.e [EXPR:10]
060209 22:40:04 [Note] EVEX EXECUTED event newdb.e[EXPR:10]. RetCode=0

Так как этот пользователь, очень вероятно, не имеет доступа к файлу регистрации ошибок, он может проверять, является ли инструкция действия события допустимой, выполняя ее непосредственно:

mysql> INSERT INTO myschema.mytable VALUES (UNIX_TIMESTAMP());
ERROR 1142 (42000): INSERT command denied to user
'jon'@'ghidora' for table 'mytable'

Проверка таблицы INFORMATION_SCHEMA.EVENTS показывает, что e_store_ts существует и включен, но столбец LAST_EXECUTED записан NULL:

mysql> SELECT * FROM INFORMATION_SCHEMA.EVENTS
     >          WHERE EVENT_NAME='e_store_ts'
     >          AND EVENT_SCHEMA='myschema'\G
*************************** 1. row ***************************
EVENT_CATALOG: NULL
EVENT_SCHEMA: myschema
EVENT_NAME: e_store_ts
DEFINER: jon@ghidora
EVENT_BODY: SQL
EVENT_DEFINITION: INSERT INTO myschema.mytable VALUES (UNIX_TIMESTAMP())
EVENT_TYPE: RECURRING
EXECUTE_AT: NULL
INTERVAL_VALUE: 5
INTERVAL_FIELD: INTERVAL_SECOND
SQL_MODE: NULL
STARTS: 0000-00-00 00:00:00
ENDS: 0000-00-00 00:00:00
STATUS: ENABLED
ON_COMPLETION: NOT PRESERVE
CREATED: 2006-02-09 22:36:06
LAST_ALTERED: 2006-02-09 22:36:06
LAST_EXECUTED: NULL
EVENT_COMMENT:
1 row in set (0.00 sec)

(Обратите внимание: до MySQL 5.1.12 не было столбца EVENT_DEFINITION, по причине чего EVENT_BODY содержал инструкцию SQL или инструкции, которые будут выполнены.

Чтобы отменить привилегию EVENT, используйте инструкцию REVOKE. В этом примере привилегия EVENT на схеме myschema удалена из логина пользователя jon@ghidora:

REVOKE EVENT ON myschema.* FROM jon@ghidora;

Важно: отмена привилегии EVENT пользователя не удаляет и не отключает никакие события, которые, возможно, были им созданы!

Например, предположим, что пользователю jon@ghidora предоставили привилегии EVENT и INSERT на схеме myschema. Этот пользователь затем создает следующее событие:

CREATE EVENT e_insert ON SCHEDULE
       EVERY 7 SECOND DO
       INSERT INTO myschema.mytable;

После того, как это событие было создано, root отменяет привилегию EVENT для jon@ghidora. Однако, e_insert продолжает выполняться, вставляя новую строку в mytable каждые семь секунд.

Определения событий сохранены в таблице 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 представляет пять переменных состояния, обеспечивающих подсчет связанных с событием операций (но не инструкций, выполненных событиями). Они:

Вы можете просматривать текущие значения для все них в одно время, выполняя инструкцию 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).

В MySQL 5.1.6 INFORMATION_SCHEMA.EVENTS показывает NULL в столбце SQL_MODE. Начиная с 5.1.7, SQL_MODE отображает то, что было в действительности, когда событие было создано.

В MySQL 5.1.6 единственным способом удалять или менять событие, созданное пользователем, который не был definer этого события, было манипулирование таблицей системы mysql.event MySQL-пользователем root или другим пользователем с привилегиями на этой таблице. В MySQL 5.1.7 и выше DROP USER удаляет все события, для которых этот пользователь был definer, также DROP SCHEMA удаляет все события, связанные с удаляемой схемой.

Как с сохраненными подпрограммами, события не перенесены к новой схеме инструкцией RENAME SCHEMA (или RENAME DATABASE).

Начиная с MySQL 5.1.8, имена событий обработаны в нечувствительном к регистру режиме. Например, это означает, что Вы не можете иметь два события в той же самой базе данных с именами anEvent и AnEvent (а до MySQL 5.1.12 еще и с тем же самым definer). Важно: если Вы имеете события, созданные в MySQL 5.1.7 или ранее, которые назначены к той же самой базе данных, имеют тот же самый definer, и чьи имена отличаются только регистром символов, то Вы бы переименовали эти события, чтобы избежать проблем с обработкой учета регистра перед обновлением до MySQL 5.1.8 или позже.

Ссылки на сохраненные подпрограммы, определяемые пользователем функции и таблицы в предложениях ON SCHEDULE инструкций CREATE EVENT и ALTER EVENT не обеспечиваются (Глюк #22830).

Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру