MySQL: руководство профессионала

Паутов Алексей В.

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).

В 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).

Глава 9. База данных INFORMATION_SCHEMA

INFORMATION_SCHEMA обеспечивает доступ к метаданным базы данных.

Метаданные представляют собой данные относительно данных, имени базы данных или таблицы, тип данных столбца или привилегии доступа. Другие термины, которые иногда используются для этой информации: каталог системы и словарь данных.

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

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

Имеется пример инструкции, которая получает информацию из INFORMATION_SCHEMA:

mysql> SELECT table_name, table_type, engine

– > FROM information_schema.tables

– > WHERE table_schema = 'db5' ORDER BY table_name DESC;

+------------+------------+--------+

| table_name | table_type | engine |

+------------+------------+--------+

| v56 | VIEW | NULL |

| v3 | VIEW | NULL |

| v2 | VIEW | NULL |

| v | VIEW | NULL |