Всем привет! Есть подобная таблица:
Нужно посчитать, сколько дней каждый USERID, был непрерывно на последнем TARIFID
В данном примере: USERID->1 был 5 раз (на TARIFID->5)

Сейчас используется ресурсоемкий алгоритм (stored procedure), который в лоб перебирает записи. Надо как-то оптимизировать.

неизвестна версия ФБ.
2.5.2
В данном примере 7 записей, а не пять.
Нужно посчитать непрерываемую последовательность, от текущего дня к "прошлому" - сколько дней на текущем TARIFID
И что такое последний TARIFID? Максимальный номер? Или последний по дате?
INTEGER, по последней дате
Есть ещё таблицы?
Нет
авторЕсли существует только одна плоская таблица, то скорее всего удастся только отсечь по датам.
Важны не даты, а сколько пробыл на текущем TARIFID
авторОстальное придётся перебирать в лоб.
Это я и так делаю, думал оптимизировать.

За остальные примеры спасибо, примерю их, отпишусь.

KreatorXXI,
Немного вроде, порядка ~60 млн записей. Индексы по ключевым значениям есть.

Данные статистические, не очень критичные, требуются для человека.
Сейчас эта статистика собирается раз в сутки, на это уходит минут ~40. Думаю сделать этот расчет по запросу, по конкретному USERID, т.к. 100% покрытие статистикой совершенно не требуется, а значит зазря 40 минут в день теряются в подсчетах.

Это за какой период 60 млн?
Это за 13 лет, в статистике участвуют последние 5.

Таки определитесь для начала: требуются на одного человека или на каждого? И насколько
часто? Для первого случая и частоты запросов менее раза в секунду - цикл при правильном
плане самое лучшее решение.
Статистические данные нужно показать оператору(ам), когда тот открывает карточку USERID.
Менее раза в секунду, конечно же.

Пока склоняюсь к созданию процедуры GET_USER_TARIF_DAYS(:USERID), которая в лоб будет считать, но только одного USERID. И конечно же нужна отдельная табличка, как правильно написал pastor , которая будет следить за состоянием статистики, если сегодня уже считали - на готовый результат. Не считали - считаем, сохраняем, возвращаем.

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

А вот это пока что выглядит совершенно избыточным. Оно бы потребовалось при
десятках-сотнях запросов в секунду по отдельным пользователям или при довольно частом
запросе по всем миллионам пользователей.
Да, эта информация показывается еще в некоторых местах (группа USERIDs, до 100 штук), там AJAX'ом будет подгружаться уже эта статистика по каждому USERID. Дважды открылась группа - это уже 200% подсчетов статистики, а можно гарантированно остановиться на 100%. Так что такое кеширование, думаю не лишним будет.

Rom1, зачем забивать таблицу избыточными данными по каждому дню, когда достаточно хранить лишь дату перехода пользователя на другой тариф?
Это билинговая система. Есть таблица тарифных планов каждого USERID, там указаны как раз-таки периоды: TARIFID, начало-окончание/начало-бесконечность.
Есть таблица реальных начислений, которые должны храниться и доставаться без каких либо вычислений - это требование аудита.
При этом тарифы абонента со временим удаляются. Поэтому статистику о том сколько USERID находится на тарифном плане, можно поднять только из реальных начислений.

Ещё напрашивается вопрос - что делать, если два разных тарифа пользователя имеют одинаковый максимальный срок действия?
Максимальный срок действия тарифа - бесконечность (без ограничения). Есть стек тарифов, они накладываются друг на друга, одни имеют приоритет над другими, короче - это компиляция. Единственные простые, плоские данные, находятся в таблице реальных начислений.

авторесть агрегат - берем его, делаем +-, переписываем агрегат. на время работы - select with lock.
нет агрегата - считаем с нуля.
Аггрегатом придется заниматься всегда и всегда помнить о нем и иметь отходные пути, которые не остановят работу на в ЧНН. Мне такая концепция не нравится.

Значит участвуют миллионов 20 записей. Если тупо пробежаться по ним, будет в районе двух минут (я бы даже дал меньше - полминуты). Скорее всего Вы своими наворотами всё портите. Как предложил Dimitry Sibiryakov, используйте запрос с курсором в хранимке. Или приведите свой запрос для начала.
Я конечно же задачу сократил до минимума, чтобы указать на суть расчета и связанной с этим проблемы. Собрать статистику, удалить данные, добавить - все это достаточно ресурсоемко, пол минуты - это тупо посчитать количество записей в начислениях, без обработки.