Форум пользователей MySQL

Коллеги, хочу поговорить о работе с постоянно и довольно интенсивно растущими таблицами.
В данном случае речь пойдёт о таблице типа сообщений форума (на самом деле о таблице с комментариями на различные сущности, но это не важно).

В день может быть сколь угодно много сообщений (сотни, тысячи и более), т.е. в год около миллиона. Ворочать такую огромную таблицу становится трудно, поэтому их (насколько я понимаю) разбивают по годам и загоняют в MyISAM compressed (сообщения, которые туда попали, называются "Архив")

Мне это не нравится по ряду причинам:

1. С точки зрения пользователя: в заархивированную тему нельзя добавить ответ - приходится заводить новую. Меня лично это бесит. Также заархивированное сообщение нельзя отредактировать (хотя это очень редко требуется).
Вообще дискриминация сообщений по времени мне не нравится - даже старые сообщения могут быть актуальными.

2. С точки зрения разработчика: приходится усложнять структуру приложения, т.к. добавляются еще один вид таблиц на одну и ту же информацию, возникают всякие MERGE (которым, если что, надо несколько файловых потоков) и др.

И я задумался, нельзя ли этого избежать. Пришло в голову следующее: вместо одной таблицы делается две: одна - с информацией, необходимой для проверки критериев, по которым сообщения выбираются - id, parentid, created, modified (ну и возможно что-то еще), вторая - с id и информацией, которая нужна только когда сообщение уже точно будет выбрано.
Обычно отображать нужно не больше 20-100 сообщений (в зависимости от того, сколько на странице). Выбирать их id из маленькой таблицы, потом выбирать всё остальное из большой по id IN (...)
Большой сделать PARTITION BY HASH(id) PARTITIONS N.
N сделать, там, я не знаю, 100 или 1000.


Что скажете?