Что быстрее, индекс или Seq Scan?

Что быстрее: индекс или Seq Scan?

Этот вопрос — классическая ловушка для разработчиков, работающих с базами данных. Короткий и правильный ответ: все зависит от конкретной ситуации. Ни один из методов не является абсолютно быстрее другого во всех случаях. Скорость определяется селективностью запроса, размером данных, типом индекса и характером нагрузки.

Последовательное сканирование (Seq Scan)

Seq Scan — это полное сканирование таблицы, где система читает все строки (точнее, все страницы данных) последовательно, от начала до конца.

• Когда Seq Scan быстрее:

    *   **При выборке большей части таблицы** (например, > 5-30%, в зависимости от СУБД и настроек). Если вам нужно 80% строк, дешевле прочитать всю таблицу одним непрерывным потоком ввода-вывода, чем совершать множество случайных обращений к индексу и затем к самой таблице (так называемый **random I/O**).
    *   **На маленьких таблицах.** Для таблиц, которые помещаются в одну или несколько страниц, планировщик запросов почти всегда выберет Seq Scan, так как накладные расходы на использование индекса превышают выгоду.
    *   **Когда столбец не индексирован.** Очевидно, если подходящего индекса нет, Seq Scan — единственный вариант.

-- Скорее всего, Seq Scan (выбираем 40% данных)
SELECT * FROM orders WHERE total_amount > 100;

Сканирование по индексу (Index Scan)

Index Scan использует структуру индекса (чаще всего B-дерево) для быстрого нахождения строк, соответствующих условию, без чтения всей таблицы.

• Когда Index Scan быстрее:

    *   **При высокой селективности** (выборке малой доли строк, например, < 1-5%). Индекс позволяет сразу перейти к нужным данным.
    *   **Для операций `ORDER BY` или `LIMIT` по индексированному полю.** Например, найти 10 последних заказов.
    *   **Для покрывающих индексов (Index Only Scan).** Если все нужные для запроса столбцы уже содержатся в индексе, системе не нужно обращаться к основной таблице (heap), что значительно ускоряет выполнение.

-- Скорее всего, Index Scan по idx_users_email (выбираем 1 строку)
SELECT * FROM users WHERE email = 'alex@example.com';

-- Index Only Scan, если индекс создан на (status, created_at)
SELECT status, created_at FROM orders WHERE status = 'shipped';

Критические аспекты для принятия решения

1. Селективность — ключевой фактор. Планировщик запросов оценивает, какую долю строк вернет условие. Если оценка неточна (из-за устаревшей статистики), может быть выбран неоптимальный план.
2. Стоимость операций ввода-вывода. Seq Scan — это в основном sequential I/O (быстрое чтение большими блоками). Index Scan для не-покрывающих индексов приводит к random I/O (медленный доступ к случайным страницам таблицы). Современные SSD уменьшают этот разрыв, но он всё ещё существенен.
3. Наличие индекса накладывает overhead. Индексы замедляют операции INSERT, UPDATE, DELETE (так как их нужно поддерживать) и занимают дополнительное место на диске.
4. Тип индекса. Для разных задач эффективны разные индексы: B-tree для равенства и диапазонов, GiST/GIN для полнотекстового поиска, BRIN для больших таблиц с коррелированным расположением данных.

Практический пример в PostgreSQL

Вы можете увидеть, как планировщик принимает решение, используя EXPLAIN ANALYZE.

EXPLAIN ANALYZE SELECT * FROM large_table WHERE category_id = 10;

Если category_id = 10 встречается редко, вы увидите в выводе Index Scan using idx_category on large_table. Если же значение 10 составляет 40% таблицы, скорее всего, будет Seq Scan on large_table.

Вывод

• Используйте индексы для высокоселективных запросов, поиска по ключу, сортировки и ограничения выборки.
• Seq Scan — эффективный и часто оптимальный способ чтения больших объемов данных или всей таблицы.

Главный принцип: не добавляйте индексы "на всякий случай". Каждый индекс должен быть обоснован конкретными медленными запросами. Анализируйте планы запросов (EXPLAIN) и понимайте, почему планировщик выбирает тот или иной путь доступа в вашем конкретном случае с вашими данными.