tags:

views:

67

answers:

1

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.

+3  A: 

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).

derobert