21.5. Event Scheduler Limitations and Restrictions
This section lists restrictions and limitations applying to event
scheduling in MySQL.
In MySQL 5.1.6, any table referenced in an event's action
statement must be fully qualified with the name of the schema in
which it occurs (that is, as
An event may not be created, altered, or dropped by a trigger,
stored routine, or another event. This is by design. However, an
event may create, alter, or drop triggers and stored routines.
The resolution of event schedules is measured in seconds. There is
no way to cause events scheduled to occur at the same second to
execute in a given order.
Execution of event statements have no affect on the server's
statement counts such as
Com_insert that are displayed by
In MySQL 5.1.6, you may not view another user's events in the
INFORMATION_SCHEMA.EVENTS table. In other
words, any query made against this table is treated as though it
contains the condition
DEFINER = CURRENT_USER()
Events cannot be created with a start time that is in the past.
In MySQL 5.1.6,
NULL in the
In MySQL 5.1.7, the
SQL_MODE displayed is that
in effect when the event was created.
In MySQL 5.1.6, the only way to drop or alter an event created by
a user who is not the definer of that event is by manipulation of
mysql.event system table by the MySQL
root user or by another user with privileges on
this table. Beginning with MySQL 5.1.7,
USER drops all events for which that user was the
definer; also beginning with MySQL 5.1.7
SCHEMA drops all events associated with the dropped
As with stored routines, events are not migrated to the new schema
RENAME SCHEMA (or
DATABASE) statement. See
Section 13.1.9, “
RENAME DATABASE Syntax”.