1. По исходному вопросу.

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

Затем. Самый грамотный путь реализации этого пути - делать таблицу in memory.

Однако есть путь более правильный (для обычных ситуаций):

1.1 Собрать коллекцию основных запросов к целевой таблице, проанализировать их, выделить группы, для них создать целевые индексы и матвьюхи (например с выборкой по фильтрующему индексу). После запросы переписать на обращение к матвьюхам.

1.2 Собссно решать проблему в её источнике. Т.е. в том, что описано вами ниже:




т.е. 1.2 -> 2

2. Если вы как компания не доросли до DWH/BI (что странно, если вы считаете таблицу 8 Гиг маленькой), то решить такое можно и в рамках обычной базы несколькими путями:

2.1 Хранимые отчёты. Заранее сформированные по расписанию и хранимые готовые данные отчётов по самым востребованным параметрам сбора отчётов. И их нужно только на форму отчёта подтянуть.

2.2 Хранимые предрассчитанные по расписанию агрегатные данные для отчётов. Такой минисрез по псевдокубу.

2.3 Оптимизация имеющихся запросов как они есть (наверняка ведь есть что оптимизировать).

2.4 Оптимизация обращения к таблицам в целом. Вьюхи, матвьюхи, индексы.

2.5 Изменение структуры данных под задачу. Например можно не считать обороты по поставщику за период каждый раз налету, а иметь такое поле в специальной таблице. Куда вносить изменения при каждой транзакции по поставщику. Там же остаток по счёту, переходящий остаток по счёту клиента и т.п.