How would you expire (or update) a MySQL record with precision to the expiry time?

Question

Last year I was working on a project for university where one feature necessitated the expiry of records in the database with almost to-the-second precision (i.e. exactly x minutes/hours after creation). I say 'almost' because a few seconds probably wouldn't have meant the end of the world for me, although I can imagine that in something like an auction site, this probably would be important (I'm sure these types of sites use different measures, but just as an example).

I did research on MySQL events and did end up using them, although now that I think back on it I'm wondering if there is a better way to do what I did (which wasn't all that precise or efficient). There's three methods I can think of using events to achieve this - I want to know if these methods would be effective and efficient, or if there is some better way:

1. Schedule an event to run every second and update expired records. I imagine that this would cause issues as the number of records increases and takes longer than a second to execute, and might even interfere with normal database operations. Correct me if I'm wrong.

2. Schedule an event that runs every half-hour or so (could be any time interval, really), updating expired records. At the same time, impose selection criteria when querying the database to only return records whose expiration date has not yet passed, so that any records that expired since the last event execution are not retrieved. While this would be accurate at the time of retrieval, it defeats the purpose of having the event in the first place, and I'd assume the extra selection criteria would slow down the select query. In my project last year, I used this method, and the event updating the records was really only for backend logging purposes.

3. At insert, have a trigger that creates a dynamic event specific to the record that will expire it precisely when it should expire. After the expiry, delete the event. I feel like this would be a great method of doing it, but I'm not too sure if having so many events running at once would impact on the performance of the database (imagine a database that has even 60 inserts an hour - that's 60 events all running simultaneously for just one hour. Over time, depending on how long the expiration is, this would add up).

I'm sure there's more ways that you could do this - maybe using a separate script that runs externally to the RDBMS is an option - but these are the ones I was thinking about. If anyone has any insight as to how you might expire a record with precision, please let me know.

Also, despite the fact that I actually did use it in the past, I don't really like method 2 because while this works for the expiration of records, it doesn't really help me if instead of expiring a record at a precise time, I wanted to make it active at a certain time (i.e. a scheduled post in a blog site). So for this reason, if you have a method that would work to update a record at a precise time, regardless of what that that update does (expire or post), I'd be happy to hear it.

Answer 1

Option 3:

At insert, have a trigger that creates a dynamic event specific to the record that will expire it precisely when it should expire. After the expiry, delete the event. I feel like this would be a great method of doing it, but I'm not too sure if having so many events running at once would impact on the performance of the database (imagine a database that has even 60 inserts an hour - that's 60 events all running simultaneously for just one hour. Over time, depending on how long the expiration is, this would add up).

If you know the expiry time on insert just put it in the table..

• library_record - id, ..., create_at, expire_at

And query live records with the condition:

expire_at > NOW()

Same with publishing:

• library_record - id, ..., create_at, publish_at, expire_at

Where:

publish_at <= NOW() AND expire_at > NOW()

You can set publish_at = create_at for immediate publication or just drop create_at if you don't need it.

Each of these, with the correct indexing, will have performance comparable to an is_live = 1 flag in the table and save you a lot of event related headache.

Also you will be able to see exactly why a record isn't live and when it expired/should be published easily. You can also query things such as records that expire soon and send reminders with ease.