Файлы VS Mysql

Есть общая страница пользователя, на которую может зайти любой другой юзер. Там идет подсчет кое-каких данных:
1. Сколько у юзера друзей
2. Сколько у юзера подарков
3. Сколько у юзера создано блогов
4. Сколько у юзера создано статусов
5. Сколько у юзера загружено фотографий
6. Сколько у юзера нарушений
7. Сколько у юзера достижений
.. И так далее. Вобщем около 30 запросов к базе. Проверил на 1 миллионной базе, выполняются они общим счетом за 0.01 - 0.03 сек.
Думаю, нафиг каждый раз всё это проверять? Ну взял и написал функцию, которая будет результаты этих запросов записывать в массив и сохранять его в временной папке юзеров, которую я назвал "tmp". Там в этой папке юзеры будут делиться на подпапки по 10.000 юзеров в каждой, в которых уже и будут лежать этих файлы с результатами для каждого юзера. А потом уже на страницах юзеров, проверять, когда был изменен файл юзера с этими результатами (подключать его, если он актуален вместо 30 запросов к базе) и через определенный промежуток обновлять его.
И вроде бы всё было хорошо, забыл про это.
Но столкнулся с такой проблемой, что если пользователю дарят подарок или у него появляются друзья, то данные берутся старые из файла, пока не истечет его период. Получается такая шляпа:
- Юзер 1 дарит подарок юзеру 2
- Юзеру 2 приходит уведомление, что ему пришел подарок и надо его посмотреть.
- Он смотрит свои подарки, а там показывает, что их нет, или показывает, что их меньше. Ведь инфа берется из файла старая и не актуальная.

Как лучше быть? Придумал пару вариантов:
1. Удалять этот файл с результами запросов (при определенных действиях, например, когда ему дарят подарок)
2. Написать скрипт, который будет обновлять параметры внутри файла (например, когда юзеру дарят подарок, то в файле тоже добавится 1)
3. Перенести в базу все эти параметры вместо файлов. И обновлять её при определенных действиях, а также дергать инфу оттуда.

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

Проект прилично посещаем.
Или же вообще не кешировать ничего и оставить эти 30 запросов к базе?
Прошу гуру помочь решить данную проблему и подсказать верное решение. Может быть у вас даже найдется свое, более лучшее?

Кэш нужно обновлять. На то он и кэш.

-----
Интернет-магазин.

Ты о браузерном кэше? Он не подходит. Некоторые части страницы должны быть в реальном времени, а не из кэша браузера.

Вот об этом кэше:


Нормальные варианты 1 и 3:
1) если вам кажется, что инвалидация дорогая - разбейте кэш на части помельче.
3) повесьте триггеры. Ночью для самопроверки можете делать перепроверку кэша.

-----
PostgreSQL DBA

Тоже нормальный вариант. И не считайте количество запросов к базе. Считайте время потраченное на их выполнение и ресурсы сервера.

во первых кешировать в файлах - глупо
во вторых откуда 30 запросов - это статистику наверняка можно выбрать и парой запросов с группировками (или написать представление) подсчет будет вестись по индексным полям а значит довольно быстро.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Как посчитать потраченные ресурсы? У меня на страницу идет вывод только количества запросов к базе, число потраченной оперативной памяти на скрипт, а также скорость генерации страницы. Также "медленные" запросы к базе и ошибки при запросах сохраняются в отдельные логи.

Тогда в чем кешировать? На сколько я знаю, то даже отдельные части страниц кешируют на .html файлах и их подключают. Нет?

Хмм.. И каким образом их объединить? Все запросы идут в разные таблицы, но общее условие "WHERE `id_login` = $id_user".

JOIN