Индексы: когда они помогают аналитику

Индексы — это структуры данных, которые СУБД создает для ускорения поиска строк в таблице. Представьте книгу на 1000 страниц: без оглавления вы листаете все подряд, с оглавлением — сразу открываете нужную главу. Индекс в базе данных работает так же.

Аналитик обычно не создает индексы сам (это задача DBA или разработчиков), но должен понимать, когда их отсутствие замедляет запросы, и уметь обосновать запрос на их создание.

Когда индексы ускоряют запросы

Ускорение WHERE-условий

Индекс наиболее эффективен для фильтрации по столбцам с высокой селективностью (много уникальных значений). Если вы регулярно фильтруете данные по user_id, order_id, email или датам — индексы на эти поля критичны.

-- Без индекса на customer_id: Seq Scan, 10 млн строк
SELECT * FROM orders WHERE customer_id = 12345;

-- С индексом: Index Scan, ~50 строк
-- Ускорение в сотни раз

Ускорение JOIN

При соединении таблиц СУБД ищет совпадения по ключам. Индексы на столбцах, участвующих в JOIN, радикально ускоряют эту операцию.

SELECT o.order_id, c.customer_name
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id;

Если на customers.customer_id есть индекс (обычно это первичный ключ, индексируемый автоматически), а на orders.customer_id нет — JOIN будет медленным. Индекс на внешнем ключе orders.customer_id обязателен для производительности.

Ускорение сортировки и GROUP BY

Индекс хранит данные в отсортированном виде. Если запрос содержит ORDER BY indexed_column, СУБД может вернуть данные сразу в нужном порядке без дорогостоящей операции сортировки.

-- С индексом на order_date: данные уже отсортированы
SELECT * FROM orders ORDER BY order_date DESC LIMIT 100;

Когда индексы НЕ помогают

Низкая селективность

Индекс на столбце с 2-3 уникальными значениями (например, is_active со значениями TRUE/FALSE) часто бесполезен. СУБД может решить, что Seq Scan всей таблицы быстрее, чем использование индекса.

Функции и вычисления в WHERE

-- Индекс на created_at НЕ используется
SELECT * FROM orders WHERE DATE(created_at) = '2024-01-15';

-- Индекс используется
SELECT * FROM orders WHERE created_at >= '2024-01-15' AND created_at < '2024-01-16';

Применение функции к индексированному столбцу делает индекс бесполезным. Переписывайте условия так, чтобы столбец был "чистым".

Выборка большого процента таблицы

Если запрос возвращает >10-20% строк таблицы, СУБД часто предпочтет Seq Scan: прочитать таблицу последовательно быстрее, чем делать тысячи случайных обращений через индекс.

Как проверить наличие индексов

PostgreSQL:

-- Все индексы таблицы
SELECT indexname, indexdef 
FROM pg_indexes 
WHERE tablename = 'orders';

-- Или через psql
\d orders

Общий подход через EXPLAIN:

EXPLAIN SELECT * FROM orders WHERE customer_id = 12345;

Если в плане Index Scan using orders_customer_id_idx — индекс есть и используется. Если Seq Scan — индекса нет или он не применяется.

Как запросить создание индекса

Когда вы обнаружили, что ваш регулярный аналитический запрос делает Seq Scan по большой таблице, соберите аргументацию:

1. Частота запроса: "Этот отчет запускается 50 раз в день"
2. Текущая производительность: "Запрос выполняется 45 секунд, EXPLAIN показывает Seq Scan на 8 млн строк"
3. Конкретное предложение: "Индекс на orders.customer_id ускорит запрос в ~100 раз"
4. Пример синтаксиса для разработчика:

CREATE INDEX idx_orders_customer_id ON orders(customer_id);

Для составных условий может потребоваться композитный индекс:

-- Для WHERE status = 'completed' AND order_date >= '2024-01-01'
CREATE INDEX idx_orders_status_date ON orders(status, order_date);

Ключевой вывод: Индексы — это не магия, а инструмент с четкими правилами применения. Аналитик должен уметь читать план выполнения, определять отсутствие нужных индексов и аргументированно запрашивать их создание у команды разработки. Правильные индексы превращают минутные запросы в секундные, делая ежедневную работу с данными комфортной.