Почему медленно
- Без подходящего индекса СУБД делает полное сканирование таблицы (full table scan) и читает все строки с диска — дорого при больших объёмах (например, при $10^7$ строках).
- Условие вида equality + range (в вашем случае $‘custome{r}_{i}d=?‘и‘create{d}_{a}t>?‘$) не оптимально обслуживается отдельными одно-колоночными индексами (может потребоваться объединение bitmap/индекс-сканов), что всё ещё даёт много I/O.
- SELECT * мешает сделать «покрывающий» (covering / index-only) запрос, поэтому даже при индексном поиске часто требуется дополнительный доступ к строке.
Какие индексы предложить (приоритеты)
- Основной вариант: композитный B-tree индекс на (customer_id, created_at). Для B-tree это оптимально при равенстве по первому столбцу и диапазоне по второму:
- SQL-пример: CREATE INDEX idx_orders_customer_created ON orders(customer_id, created_at);
- Если часто сортируете по дате в обратном порядке, можно явно задать направление: (customer_id, created_at DESC).
- Если запросы иногда фильтруют только по created_at — отдельный индекс на created_at поможет этим запросам.
- Для очень больших, преимущественно временных данных можно рассмотреть BRIN-индекс по created_at (экономно по месту) — эффективен если данные физически кластеризованы по времени.
- Покрывающий индекс: если вы выбираете не все столбцы, а только несколько — добавьте INCLUDE (или эквивалент) для уменьшения обращений к таблице: например (customer_id, created_at) INCLUDE (status, amount).
- Альтернативы/масштабирование: партицирование по created_at (range) или по customer_id для уменьшения объёма сканируемых партиций.
Побочные эффекты и ограничения
- Запись медленнее: каждое INSERT/UPDATE/DELETE должно поддерживать все индексы — стоимость записи растёт примерно пропорционально числу индексов $n$.
- Место на диске: индексы занимают дополнительное хранилище.
- Нужен контроль за фрагментацией/сбалансированностью и за статистиками — при устаревших статистиках оптимизатор может выбрать плохой план.
- Создание индекса может блокировать таблицу (в зависимости от СУБД) — для больших таблиц использовать ONLINE/CONCURRENT опции.
- Низкокардинальные поля (мало уникальных значений) дают мало выигрыша от индекса.
- SELECT * мешает индекс‑только сканам: либо ограничьте выбираемые столбцы, либо включайте часто используемые поля в INCLUDE.
- BRIN и партиции дают меньшую точность/сложность управления и подходят не для всех паттернов доступа.
Рекомендации по практике
- Сделайте композитный индекс (customer_id, created_at) как первичную рекомендацию.
- Используйте EXPLAIN ANALYZE, чтобы проверить план и реальную выгоду.
- Ограничьте SELECT * — выбирайте только нужные столбцы, чтобы иметь шанс на индекс‑только выполнение.
- При больших объёмах рассмотрите партицирование и BRIN для экономии места и ускорения сканирования старых данных.