Question

I have a table where when a row is created, it will be active for 24 hours with some writes and lots of reads. Then it becomes inactive after 24 hours and will have no more writes and only some reads, if any.

Is it better to keep these rows in the table or move them when they become inactive (or via batch jobs) to a separate table? Thinking in terms of performance.

Answer 1

This depends largely on how big your table will get, but if it grows forever, and has a significant number of rows per day, then there is a good chance that moving old data to another table would be a good idea. There are a few different ways you could accomplish this, and which is best depends on your application and data access patterns.

1. Essentially as you said, when a row becomes “old”, INSERT to the archive table, and DELETE from the current table.

2. Create a new table every day (or perhaps every week, or every month, depending on how big your dataset is), and never worry about moving old rows. You’ll just have to query old tables when accessing old data, but for the current day, you only ever access the current table.

3. Have a “today” table and a “all time” table. Duplicate the “today” rows in both tables, keeping them in sync with triggers or other mechanisms. When a row becomes old, simply delete from the “today” table, leaving the “all time” row in tact.

One advantage to #2, that may not be immediately obvious, is that I believe MySQL indexes can be optimized for read-only tables. So by having old tables that are never written to, you can take advantage of this extra optimization.