I've got a use case for creating temporary users on a MySQL database, and then dropping them after 24 hours. I'll be doing this enough that I'd like to automate the process and package it with the user creation script, so that I don't have to keep track of the process.
I've looked around the internet for docs, questions, gossip about the performance implications of MySQL event scheduling, but I haven't found anything discouraging. I've seen another question about the "cost" MySQL scheduled events, but the discussion mostly covers a comparison between scheduling DB tasks using cron
vs. using MySQL event scheduling.
I'm running on Amazon RDS, so cron
won't work for me. MySQL event scheduling looks like the right solution. I'm scheduling a pretty lightweight event--dropping one user at a time, 24 hrs after creation--but I'll have to keep MySQL's event scheduler enabled 24/7. Is there any performance cost to this? If not, why isn't the event scheduler enabled by default?
Summary: in this tutorial, you will learn about MySQL event scheduler and how to create events to automate repetitive database tasks. MySQL Events are tasks that execute according to a specified schedule. Therefore, sometimes MySQL events are referred to as scheduled events. MySQL Events are named object which contains one or more SQL statement.
For example, you can create an event that optimizes all tables in the database that runs at 1:00 AM every Sunday. MySQL Events are also known as “temporal triggers” because they are triggered by time, not by DML events like normal triggers. MySQL events are similar to a cronjob on Linux or a task scheduler on Windows.
The book High Performance MySQL discusses this: Events are initiated by a separate event scheduler thread, because they have nothing to do with connections. They accept no inputs and return no values -- there's no connection for them to get inputs from or return values to....
I suspect that events are not enabled by default because they have an impact on statement-based replication, which High Performance MySQL also discusses: [E]vents can cause the same types of problems with statement-based replication that other stored code can cause.
The cost of the scheduler is irrelevant, compared to the cost of the SQL the scheduler runs. The book High Performance MySQL discusses this:
Events are initiated by a separate event scheduler thread, because they have nothing to do with connections. They accept no inputs and return no values -- there's no connection for them to get inputs from or return values to.... Similar considerations to those that apply to stored procedures apply to events. First, you are giving the server additional work to do. The event overhead itself is minimal, but the SQL it calls can have a potentially serious impact on performance.
I suspect that events are not enabled by default because they have an impact on statement-based replication, which High Performance MySQL also discusses:
[E]vents can cause the same types of problems with statement-based replication that other stored code can cause.
Ultimately, like any database problem, you have to implement the solution in your schema and measure the effects because no two instances are alike and no solution is universal.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With