How can I determine when an InnoDB table was last

Question

I've had success in the past storing the (heavily) processed results of a database query in memcached, using the last update time of the underlying tables(s) as part of the cache key. For MyISAM tables, that last changed time is available in SHOW TABLE STATUS. Unfortunately, that's usually NULL for InnoDB tables.

In MySQL 4.1, the ctime for an InnoDB in its SHOW TABLE STATUS line was usually its actual last update time, but that doesn't seem to be true for MySQL 5.1.

There is a DATETIME field in the table, but it only shows when a row has been modified - it cannot show the deletion time of a row that's not there anymore! So, I really cannot use MAX(update_time).

Here's the really tricky part. I have a number of replicas that I do reads from. Can I figure out the state of the table that doesn't rely on when the changes have actually been applied?

My conclusion after working on this for a while is that it's not going to be possible to get this information as cheaply as I'd like. I'm probably going to cache data until the time that I expect the table to change (it's updated once a day), and let the query cache help out where it can.

Answer 1

I would suggest adding another column to the table and let MySQL keep track of when the table was last modified, something like this:

ADD COLUMN `last_update` TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL

Answer 2

If you're not really interested when the database was changed, but want to know wether or not one database table was changed you should look into MySQL CHECKSUM TABLE

Hope this helps.

Answer 3

This is MySQL bug 14374, 15438, and underlying InnoDB bug 2681.

I have two suggestions (other than patching MySQL).

1. If you're using one table per file (innodb_file_per_table), stat the underlying file. You could write a MySQL function/extension to do this. This may lag slightly, due to database caching.
2. You can use after update, delete, and insert triggers to keep your own metadata table with the last update times for each table you're concerned with.

I'd personally suggest the second, as its much more portable and doesn't depend on implementation details (such as innodb_file_per_table).