Event triggers (events) let MariaDB run SQL automatically at scheduled times without external cron jobs.
An event trigger (simply “event”) stores a SQL statement and a schedule. When the schedule fires, the server executes the statement automatically, enabling periodic cleanup, summary tables, or report generation without external schedulers.
Run SET GLOBAL event_scheduler = ON;
or start MariaDB with --event-scheduler=ON
.Without this switch, no events run even if they exist.
Use CREATE EVENT
followed by a schedule: ON SCHEDULE AT
for a one-off task, or EVERY ... STARTS ...
for recurring tasks. Add ON COMPLETION PRESERVE
to keep one-off events after they run.
Create an event on the Orders
table that archives completed orders older than a year.The example below shows a nightly run at 02:00.
Use ALTER EVENT
to change schedules or body, ALTER EVENT ... ENABLE | DISABLE
to toggle execution, and DROP EVENT
to remove it entirely.
Keep event bodies idempotent so reruns cause no harm. Use qualified table names and LIMIT to avoid long locks.Monitor the information_schema.EVENTS
table for status and last execution time.
Most often the global event_scheduler
is OFF. Enable it and re-check the next execution timestamp in SHOW EVENTS
.
The event executes with the DEFINER user’s rights. Ensure that user still exists and has the correct permissions on referenced tables.
.
Run SHOW EVENTS\G
or query information_schema.EVENTS
for next_run and status columns.
Yes. Temporarily change the schedule with ALTER EVENT ... ON SCHEDULE AT NOW()
. After it fires, set the original schedule again.
Events are replicated to slaves by default. Disable with --replicate-wild-ignore-table=mysql.event
if needed.