Оптимизация SQL

Feb 16, 2009 09:24


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

Посмотреы в код, узнал, что у меня делается один селект на юзеров, после чего два-три селекта на каждого юзера для подсчета баланса плюс один селект на каждого для получения списка услуг. Это как-то дофига в сумме то.

Если вывести подсчет всего этого в один селект, то сначала я сломаю свой мозг придумыванием этого селекта, а потом об этот селект надолго задумается мускль.

А между тем, и баланс юзера и количество услуг величины вычисляемые и нечасто меняющиеся, а значит - их можно закешировать. И отсюда вопрос - я вижу три варианта.

Вариант 1. Кешируем в мемкеше. Если данных нет - вычисляем. Плюсы - все хорошо, да еще и свою обертку напишу, в будущем пригодится, минусы - возится много, обертку на "что делать, если в кеше нету" писать муторно. Подвид этого варианта - мускульные таблицы в памяти.

Вариант 2. Создать таблички user_balance_cache и user_orders_canche и туда кидать данные при каждом обновлении циферок в основных таблицах. Это можно сделать головоломательно через триггеры в мускле или по-простому дописав код в модули - все равно я почти все вызываю через свои модули, а не в мускль напрямую пишу.

Вариант 3. Создать табличку user_cache, в ней кучу полей и кидать туда те однострочные данные аналогично варианту 2, которые занимают 1-2-3 поля.

Я, пожалуй, склоняюсь к варианту 3, но может быть у кого-нибудь еще есть соображения по этому поводу?

ps: а потом у нас получается один селект из двух таблиц с склейкой по юзер.ид.

dev, Биллинг, sql

Previous post Next post
Up