vyegorovЯ поддерживаю решение с частичным индексом, я бы предпочел такое решение партиционированию....
С индексом проблемы нет. Доступ собственно к индексу должен быть примерно одинаков

А вот про саму таблицу "не все так очевидно" ( C ) дочь офицера

Встречался с ситуациями, когда приложение выбирало большое кол-во данных из таблице по индексу и, похоже, начинал влиять такой фактор как фрагментация данных в таблице. Т.е., выбираем 1000 коротких записей по конкретному пользователю, но из-за того, что они создавались в разное время и в вперемешку с чужими записями, фактически вычитываем 1000 блоков БД. Получаем 1000 случайных IO операций которые стоят колом на системе хранения.

Таблица была большая ( > 40-50 Gb) т.ч. надежды на кеширование не было + из-за той же фрагментации, фактически вся таблица была "горячая". Т.ч. никакого эффекта "будет всегда горячим, как и та часть таблицы, которую он охватывает" не было и в помине.

На Oracle вылечилось созданием мега-индекса, где были перечислены все необходимые для запроса поля. Доступ начал происходит к отсортированной информации, кол-во считывание блоков с диска для запросов упало на порядки (ускорение было в 100-ни раз, десятки минут -> секунды).

Возможно, более "грамотным" решением на Oracle были бы Index organized table или partition, но создание мега-широкого индекса показалось предпочтительнее (по тестам, индех организованные таблицы крайне странно работали с точки зрения производительности).

авторМой совет - да 100% имеет смысл. Просто потому что actions на 1-2Gb будет эффективно кешироваться в памяти базы а вот общая таблица с историей - далеко не факт (и скорее всего в таблицу истории особо никто ходить не будет).

плюсуюсь. На этом действительно можно сильно выиграть (а может и нет, все зависит от Ваших данных и запросов).