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

Синхронизации события, использующие интервалы YEAR, QUARTER, MONTH и YEAR_MONTH отсчитываются в месяцах, любой другой интервал отсчитывается в секундах. Не имеется никакого способа заставить планируемые события, происходящие в тот же самый момент, выполниться в заданном порядке. Кроме того, из-за округления, характера прикладных программ и того факта, что ненулевой отрезок времени требуется, чтобы создать событие и сообщить о выполнении, события могут быть отсрочены на целых 1 или 2 секунды. Однако, время, показанное в столбце LAST_EXECUTED таблицы INFORMATION_SCHEMA.EVENTS или столбце last_executed таблицы mysql.event является всегда точным до секунды относительно момента, когда событие было фактически выполнено ( Глюк #16522 Алексей В. Паутов MySQL: руководство профессионала Введение Это не совсем книга. Просто по ходу работы и изучения пакета у меня накопилось немало заметок, которые я в конце концов собрал воедино и опубликовал с оглавлением и под единым названием. Данные заметки относятся к версиям 4 и 5 пакета MySQL. По ходу текста особо отмечены места, относящиеся к специфической версии пакета. Необходимо также отметить, что эти заметки логически продолжают книгу MySQL: Руководство администратора и ориентированы на ту же аудиторию. Данный материал подготовлен Паутовым Алексеем в рамках некоммерческого проекта RussianLDP:MySQL. При любом использовании ссылка на автора и проект обязательна! ).

Выполнение инструкций события не воздействует на серверные счетчики, вроде 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: руководство профессионала Введение Это не совсем книга. Просто по ходу работы и изучения пакета у меня накопилось немало заметок, которые я в конце концов собрал воедино и опубликовал с оглавлением и под единым названием. Данные заметки относятся к версиям 4 и 5 пакета MySQL. По ходу текста особо отмечены места, относящиеся к специфической версии пакета. Необходимо также отметить, что эти заметки логически продолжают книгу MySQL: Руководство администратора и ориентированы на ту же аудиторию. Данный материал подготовлен Паутовым Алексеем в рамках некоммерческого проекта RussianLDP:MySQL. При любом использовании ссылка на автора и проект обязательна! ).

В 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 Алексей В. Паутов MySQL: руководство профессионала Введение Это не совсем книга. Просто по ходу работы и изучения пакета у меня накопилось немало заметок, которые я в конце концов собрал воедино и опубликовал с оглавлением и под единым названием. Данные заметки относятся к версиям 4 и 5 пакета MySQL. По ходу текста особо отмечены места, относящиеся к специфической версии пакета. Необходимо также отметить, что эти заметки логически продолжают книгу MySQL: Руководство администратора и ориентированы на ту же аудиторию. Данный материал подготовлен Паутовым Алексеем в рамках некоммерческого проекта RussianLDP:MySQL. При любом использовании ссылка на автора и проект обязательна! ).

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 |

| tables | BASE TABLE | MyISAM |

| t7 | BASE TABLE | MyISAM |

| t3 | BASE TABLE | MyISAM |

| t2 | BASE TABLE | MyISAM |

| t | BASE TABLE | MyISAM |

| pk | BASE TABLE | InnoDB |

| loop | BASE TABLE | MyISAM |

| kurs | BASE TABLE | MyISAM |

| k | BASE TABLE | MyISAM |

| into | BASE TABLE | MyISAM |

| goto | BASE TABLE | MyISAM |

| fk2 | BASE TABLE | InnoDB |

| fk | BASE TABLE | InnoDB |

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

17 rows in set (0.01 sec)

Объяснение: инструкция запрашивает список всех таблиц в базе данных db5 в обратном алфавитном порядке, показывая только три части информации: имя таблицы, тип таблицы и тип памяти.

Каждый пользователь MySQL имеет право обратиться к этим таблицам, но может видеть только строки в таблицах, которые соответствуют объектам, для которых пользователь имеет соответствующие привилегии доступа. В некоторых случаях (например, столбец ROUTINE_DEFINITION в таблице INFORMATION_SCHEMA.ROUTINES), пользователи, которые имеют недостаточные привилегии, будут видеть NULL.