werw

Если прямо-таки жестко быстро нужно иметь доступ к аккумулированным данным, то нужно их также аккумулировать постоянно и постепенно в течение суток - сохраняя в специальной таблице.

Возможно это делать прямо при обновлении данных в первичной таблице или по задним числом - это смотря по характеру данных, алгоритму и требований к доступности/оперативности извлечения данных.

Если требования не жесткие, то есть данные нужно получать изредка и не очень быстро и посему нет смысла отдельную таблицу городить, то - посмотреть внимательнее на индексы и запросы. Может, используются не те индексы? Так как 40 Г для современного железа не является большой проблемой. Что говорит сервер по "план запроса"?

При жестких требованиях на скорость можно агрегировать прямо в оперативной памяти, например, при помощи Tarantool, это будет довольно быстро. Наверняка, агрегированная база данных в разы меньше основной, то есть при наличие 40 Г БД выделить 4 Г на хранение агрегированных данных в оперативной памяти для нынешних серверов не является проблемой.

Ну насчет 100500 это вы хватили. Такие масштабы - другими мозгами реализуются.

Но, к примеру, мои сервера выдерживают и 10 000 в секунду, и даже с запасом, как показывают тесты.
Ничего там умного нет внутри.

Для начала провести замеры и найти самое узкое место.
Как показывает практике не нужно все переписывать, достаточно побороть 2-3 самых узких места.

У вас неправильна сама постановка задачи: "сервер зависает и перестает...."
Ну ставьте записи в лог, анализируйте.
Делайте замеры специальные, ищите узкое место.

Дело не в MySQL, Apache, Yii - они вносят не столь серьезных вклад тормозов.

Дело прежде всего в вашем коде - а кто его знает кроме вас.
Может, вы попросту совершили типичный глупый косяк начинающего программера:
https://habrahabr.ru/post/113298/