Коротко — исходный запрос неполон и на больших объёмах данных может быть очень медленным и/или давать неожиданные результаты. Ниже — перечень потенциальных проблем, рекомендации по индексам и варианты реорганизации для аналитики и онлайн‑отчётности.

1) Проблемы корректности

В SQL должен быть GROUP BY: запрос должен выглядеть так:
SELECT user_id, COUNT(*) FROM orders WHERE created_at > NOW() - INTERVAL '30 days' GROUP BY user_id;
Иначе в большинстве СУБД это либо ошибка, либо неправильный результат.Погрешности со временем и часовыми поясами:
created_at может быть TIMESTAMP WITH/WITHOUT TIME ZONE — сравнение надо делать осознанно.NOW() возвращает момент начала транзакции (в PostgreSQL) — это обычно OK, но лучше передать конкретное значение из приложения, чтобы план запроса был стабильным.MVCC/видимость: COUNT(*) подсчитывает видимые строки; недавно удалённые/обновлённые записи могут повлиять. Для строго «на момент времени» нужно контролировать консистентность транзакций.Границы интервала: > vs >= — решите, включать ли крайнюю дату.

2) Проблемы производительности (на больших данных)

Полный скан таблицы (seq scan) если нет подходящего индекса → медленно.Большое число уникальных user_id → агрегирование (GROUP BY) может требовать много памяти и/или диск‑spill (work_mem в Postgres), медленная сортировка/хэширование.Неподходящий порядок колонок в индексе может не помочь.Index-only scan возможен только если индекс покрывает нужные колонки и видимость строк отмечена (Postgres visibility map).Любые функции над created_at (например DATE(created_at)) разрушат использование индекса.План запроса может меняться со временем (статистика), что потребует ANALYZE/REINDEX.

3) Как индексировать
Цель — быстро отфильтровать по created_at и эффективно агрегировать по user_id.

Варианты индексов (Postgres и MySQL — синтаксис чуть отличается):

Базовый: ускоряет WHERE created_at:
CREATE INDEX idx_orders_created_at ON orders (created_at);Комбинированный, полезный для текущего запроса (фильтрация + покрытие):
CREATE INDEX idx_orders_created_at_userid ON orders (created_at, user_id);
Этот индекс позволяет быстро найти все строки за последние 30 дней и сразу читать user_id из индекса (в Postgres — возможно index-only scan, если нет доступа к heap).Альтернативный комбинированный:
CREATE INDEX idx_orders_userid_createdat ON orders (user_id, created_at);
Он полезен, если часто выполняете GROUP BY user_id с дополнительными фильтрами по created_at конкретных пользователей (например, WHERE user_id = X AND created_at > ...). Но для глобального фильтра по created_at менее выгоден, т.к. не позволяет эффективно сделать range scan по created_at для всех user_id.INCLUDE (Postgres) / covering index (MySQL):
В Postgres можно: CREATE INDEX idx ON orders (created_at) INCLUDE (user_id);
Это делает индекс «покрывающим» и повышает шансы на index-only scan.Партиционирование:
Range-партиционирование по created_at (по месяцу/неделе/дню) — для запросов по «последние N дней» позволит читать только последние партиции.В MySQL можно партиционировать по RANGE/YEAR/etc.Частичные индексы:
В PostgreSQL можно создать partial index для «недавних» данных, но условие должно быть константой. Часто делается на уровне партиций (каждая партиция имеет индекс).

4) Переписывание запроса (оптимизация)

Правильный SQL:
SELECT user_id, COUNT(*) AS cnt
FROM orders
WHERE created_at >= :ts_30_days_ago
GROUP BY user_id;
Где :ts_30_days_ago — значение вычисленное в приложении (не NOW() в тексте запроса), чтобы план был стабильным и чтобы можно было кешировать запросы/планы.Для "топ N" пользователей:
SELECT user_id, COUNT(*) AS cnt
FROM orders
WHERE created_at >= :ts_30_days_ago
GROUP BY user_id
ORDER BY cnt DESC
LIMIT 100;
Добавьте этот LIMIT, чтобы не возвращать миллионы строк.

5) Для аналитики и онлайн‑отчётности (рекомендации архитектуры)

Материализованные агрегаты / summary tables:
Поддерживаемая таблица user_daily_orders(user_id, day, cnt). Обновлять батчами (ETL) или инкрементально (CDC, триггеры, фоновые задачи).Для запросов "за последние 30 дней" агрегировать по дню: SUM(cnt) WHERE day >= current_date - 29.
Преимущество: запросы очень быстрые, нагрузка на OLTP минимальна.Материализованные представления (Postgres):
CREATE MATERIALIZED VIEW mv_user_day AS SELECT user_id, date_trunc('day', created_at) AS day, count(*) FROM orders GROUP BY ...Обновлять REFRESH MATERIALIZED VIEW CONCURRENTLY периодически.TimescaleDB / ClickHouse / OLAP хранилище:
Использовать специализированный движок для аналитики: ClickHouse, BigQuery, Redshift, Snowflake, ClickHouse отлично справляется с time‑series и большими агрегатами.Continuous aggregates (TimescaleDB) — автоматические обновляемые агрегаты по времени.Streaming/real‑time: использовать Kafka + stream processor (Flink, Materialize) или OLAP с инкрементальным обновлением для near real‑time отчётов.Approximate/Sketches: если нужна приближённая оценка (например, count distinct), использовать HyperLogLog, t-digest и т.п.

6) Практические советы и настройки

Перед деплоем индекса проанализируйте селективность: если последних 30 дней — малая часть таблицы → индекс по created_at очень эффективен.Проверьте plan: EXPLAIN (ANALYZE, BUFFERS) SELECT ...tuning: увеличить work_mem для больших агрегатов временно или выполнять агрегацию по частям.Vacuum/ANALYZE регулярно — чтобы статистика и visibility map были актуальны (для index-only scan).Параллельные планы: убедитесь, что конфигурация СУБД позволяет параллельный сбор агрегатов (Postgres parallel aggregate).Используйте prepared statements / bind parameters для :ts_30_days_ago, чтобы планы переиспользовались.

7) Примеры DDL/SQL (Postgres)

Правильный запрос:
SELECT user_id, COUNT(*) AS cnt
FROM orders
WHERE created_at >= now() - INTERVAL '30 days'
GROUP BY user_id;Индекс, ускоряющий фильтр и делающий покрывающим:
CREATE INDEX CONCURRENTLY idx_orders_created_at_userid ON orders (created_at, user_id);
-- или
CREATE INDEX CONCURRENTLY idx_orders_created_at_include_userid ON orders (created_at) INCLUDE (user_id);Партиционирование (пример — по месяцу):
ALTER TABLE orders
PARTITION BY RANGE (created_at);
CREATE TABLE orders_2025_10 PARTITION OF orders FOR VALUES FROM ('2025-10-01') TO ('2025-11-01');

8) Примеры архитектурного подхода

OLTP + OLAP:
OLTP (Postgres) хранит «orders».Ночью/вечером ETL → OLAP (ClickHouse/Redshift) или summary‑table.Отчёты читают агрегаты в OLAP/summary.Near‑real time:
CDC (Debezium) → Kafka → stream processor → update summary table / materialized view.

Короткое резюме

Добавьте GROUP BY и явно задавайте границу времени (параметром).Индексируйте created_at; для лучшей производительности используйте композиционные/покрывающие индексы и/или партиционирование.Для больших объёмов и онлайн‑отчётности лучше использовать материализованные/инкрементальные агрегаты или перенос аналитики в специализированный OLAP‑стек.

Если хотите, могу:

предложить конкретный индекс/партиционирование, опираясь на вашу статистику (количество строк, доля последних 30 дней, тип created_at),показать EXPLAIN‑план для примера и подсказать дальнейшие шаги,предложить SQL для построения ежедневной summary‑таблицы и процедуры её обновления.