STARTS: для многоразовых событий, чье определение включает предложение STARTS, этот столбец содержит соответствующее значение DATETIME. Как и со столбцом EXECUTE_AT, это значение решает любые используемые выражения.
Если не имеется никакого предложения STARTS, воздействующего на синхронизацию события, этот столбец пуст. До MySQL 5.1.8 это содержало NULL в таких случаях.
ENDS: то же самое, но для предложения ENDS.
STATUS: одно из двух значений: ENABLED или DISABLED.
ON_COMPLETION: одно из двух значений: PRESERVE или NOT PRESERVE.
CREATED: дата и время, когда событие было создано. Это значение DATETIME.
LAST_ALTERED: дата и время, когда событие было в последний раз изменено. Это значение DATETIME. Если событие не изменялось, начиная с создания, этот столбец хранит то же самое значение, что и столбец CREATED.
LAST_EXECUTED: дата и время, когда событие в последний раз выполнилось. Значение DATETIME. Если событие никогда не выполнялось, значение этого столбца NULL.
EVENT_COMMENT: текст комментария, если событие его имеет. Если не имеется никакого комментария, значение этого столбца пустая строка.
Пример: предположите, что пользователь jon@ghidora создает событие e_daily, а затем изменяет его через несколько минут, используя инструкцию ALTER EVENT, как показано здесь:
DELIMITER |
CREATE EVENT e_daily ON SCHEDULE EVERY 1 DAY
STARTS CURRENT_TIMESTAMP + INTERVAL 6 HOUR DISABLE
COMMENT 'Saves total number of sessions and
clears the table once per 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 ;
ALTER EVENT e_daily ENABLED;
Обратите внимание, что комментарии могут охватывать много строк.
Этот пользователь может затем выполнять следующую инструкцию SELECT и получать показанный вывод:
mysql> SELECT * FROM INFORMATION_SCHEMA.EVENTS
> WHERE EVENT_NAME = 'e_daily' AND
> EVENT_SCHEMA = 'myschema'G
*************************** 1. row ***************************
EVENT_CATALOG: NULL
EVENT_SCHEMA: myschema
EVENT_NAME: e_daily
DEFINER: jon@ghidora
EVENT_BODY: BEGIN
INSERT INTO site_activity.totals (when, total)
SELECT CURRENT_TIMESTAMP, COUNT(*) FROM site_activity.sessions;
DELETE FROM site_activity.sessions;
END
EVENT_TYPE: RECURRING
EXECUTE_AT: NULL
INTERVAL_VALUE: 1
INTERVAL_FIELD: INTERVAL_DAY
SQL_MODE: NULL
STARTS: 2006-02-09 10:41:23
ENDS: NULL
STATUS: ENABLED
ON_COMPLETION: DROP
CREATED: 2006-02-09 14:35:35
LAST_ALTERED: 2006-02-09 14:41:23
LAST_EXECUTED: NULL
EVENT_COMMENT: Saves total number of sessions and
clears the table once per day.
1 row in set (0.50 sec)
Важно: времена, отображаемые столбцами STARTS, ENDS и LAST_EXECUTED в настоящее время даны в терминах универсального времени (GMT или UTC), независимо от установки часового пояса сервера. Это верно и для столбцов starts, ends и last_executed в таблице mysql.event, а также для столбцов Starts и Ends в таблице SHOW [FULL] EVENTS. Зато столбцы CREATED и LAST_ALTERED используют часовой пояс сервера (также, как столбцы created и last_altered в таблице mysql.event), чтобы Вам жизнь медом не казалась.
Например, событие e_daily, показанное ранее, было создано на компьютере в Brisbane, Australia, в 14:35:35 9 февраля 2006. Восточное стандартное время Австралии, которое также может быть выражено как GMT+10.00. Определение события модифицировалось (используя ALTER EVENT) на несколько минут позже, в 14:41:23. Это значения, отображаемые для CREATED и LAST_ALTERED. Событие планируется, чтобы начать выполнять 6 часов спустя, в 20:41:23 в тот же самый лень, по местному времени. Вычитание 10 часов из этого, чтобы получить универсальное время выдает 10:41:23, и это то значение, которое показывается для STARTS.
На это использование универсального времени нельзя положиться в прикладных программах, поскольку ожидается изменить на сервере местное время (Глюк #16420).
9.21. Таблица INFORMATION_SCHEMA FILES
Таблица FILES обеспечивает информацию относительно файлов, в которых сохранены данные дисковых таблиц MySQL NDB.
INFORMATION_SCHEMA
Name
