Как количество JOIN-ов влияет на скорость запроса?

Как количество JOIN-ов влияет на скорость запроса?

Количество JOIN-ов критически влияет на производительность SQL запросов. Это не всегда прямая зависимость, и важно понимать механизм влияния.

Основной принцип

Квантество JOIN-ов влияет на скорость косвенно. Сам по себе JOIN — это не проблема, проблема в:

1. Объёме данных, которые нужно сравнить
2. Отсутствии индексов на ключах JOIN
3. Сложности плана выполнения (query optimizer)

Как работает JOIN

Nested Loop (самый частый случай)

Nested Loop — базовый алгоритм JOIN:

Для каждой строки из таблицы A {
  Найти совпадающие строки в таблице B
}

Сложность: O(N × M), где N — размер таблицы A, M — размер таблицы B.

Пример:

SELECT * FROM users u JOIN orders o ON u.id = o.user_id;

Если:

• users: 10,000 записей
• orders: 100,000 записей

Без индекса: 10,000 × 100,000 = 1 млн операций сравнения

Hash Join

Оптимизатор может использовать Hash Join если доступна память:

1. Загрузить всю таблицу A в хеш-таблицу в памяти
2. Для каждой строки из B: найти в хеше

Сложность: O(N + M) — намного быстрее!

Merge Join

Если обе таблицы отсортированы по ключу JOIN:

1. Отсортировать A по join_key
2. Отсортировать B по join_key
3. Слить упорядоченные последовательности

Сложность: O(N + M)

Влияние количества JOIN-ов

1 JOIN

SELECT u.*, o.amount
FROM users u
JOIN orders o ON u.id = o.user_id;

План выполнения:

Join
  -> Seq Scan on users u
  -> Index Scan on orders o (user_id)

Время: ~100ms (при правильных индексах)

2 JOIN-а

SELECT u.*, o.amount, p.name
FROM users u
JOIN orders o ON u.id = o.user_id
JOIN products p ON o.product_id = p.id;

План выполнения:

Join (orders <-> products)
  -> Join (users <-> orders)
    -> Seq Scan on users u
    -> Index Scan on orders o
  -> Index Scan on products p

Время: ~150-200ms (зависит от размера результатов)

3-4 JOIN-а

SELECT u.*, o.amount, p.name, c.category
FROM users u
JOIN orders o ON u.id = o.user_id
JOIN products p ON o.product_id = p.id
JOIN categories c ON p.category_id = c.id;

Плансложность растёт:

Join (products <-> categories)
  -> Join (orders <-> products)
    -> Join (users <-> orders)
      -> (базовый набор)

Время: ~300-500ms (может экспоненциально расти)

Факторы, влияющие на скорость

1. Индексы

С индексами на FK:

INDEX idx_orders_user_id ON orders(user_id);
INDEX idx_products_id ON products(id);

Результат: O(log N) lookup вместо O(N) full scan Ускорение: 1000x для больших таблиц!

Без индексов:

Full Table Scan на каждый JOIN
Это катастрофа даже с одним JOIN-ом

2. Размер результата

Маленький результат (10 строк):

SELECT ...
FROM ... (5 JOIN-ов)
WHERE user_id = 123;  -- очень специфичный фильтр

Время: ~50ms (даже с 5 JOIN-ов!) Причина: фильтр сокращает данные в начале.

Большой результат (1 млн строк):

SELECT ...
FROM ... (всего 2 JOIN-а)
-- без WHERE

Время: может быть 10+ сек Причина: нужно JOIN-ить миллион строк.

3. Selectivity (какой % строк прошёл через WHERE)

Высокая selectivity (1% прошёл через WHERE):

1,000,000 rows -> WHERE -> 10,000 rows -> JOIN-ы
Далее JOIN-ить только 10,000 строк

Низкая selectivity (90% прошёл через WHERE):

1,000,000 rows -> WHERE -> 900,000 rows -> JOIN-ы
Далее JOIN-ить 900,000 строк

4. Optimizer Intelligence

Современные оптимизаторы (PostgreSQL, MySQL 8+) выбирают оптимальный порядок JOIN-ов:

Этот запрос:
SELECT ... FROM A JOIN B JOIN C JOIN D ...

Оптимизатор может переупорядочить как:
JOIN D JOIN C JOIN B JOIN A

Если это быстрее!

Эмпирические данные

На реальной БД (PostgreSQL 15, индексированная):

Вывод: Объём результата влияет больше, чем количество JOIN-ов!

Проблемные паттерны

1. Тяжёлые JOIN-ы без фильтра

-- ПЛОХО: 5 JOIN-ов без WHERE
SELECT * FROM users u
JOIN orders o ON u.id = o.user_id
JOIN products p ON o.product_id = p.id
JOIN categories c ON p.category_id = c.id
JOIN reviews r ON p.id = r.product_id
JOIN ratings rt ON r.id = rt.review_id;

-- ХОРОШО: добавить WHERE для сокращения строк
WHERE u.created_at > '2024-01-01' AND p.category_id = 5;

2. JOIN с функциями

-- ПЛОХО: функция в JOIN условии
JOIN orders o ON YEAR(u.created_at) = YEAR(o.date);

-- ХОРОШО: функцию в индекс или WHERE
WHERE u.created_at >= '2024-01-01'
AND u.created_at < '2025-01-01'
JOIN orders o ON u.id = o.user_id;

3. JOIN таблиц без индексов

-- ПЛОХО: нет индекса на user_id
JOIN orders o ON u.id = o.user_id;  -- Full table scan!

-- ХОРОШО: создать индекс
CREATE INDEX idx_orders_user_id ON orders(user_id);

Оптимизация JOIN-ов

1. Добавить индексы на FK

CREATE INDEX idx_orders_user_id ON orders(user_id);
CREATE INDEX idx_products_category_id ON products(category_id);

2. Использовать EXPLAIN для анализа

EXPLAIN ANALYZE
SELECT ... FROM users u JOIN orders o ...;

-- Посмотреть:
-- - Sequential Scan vs Index Scan
-- - Actual rows vs Estimated rows
-- - Execution time

3. Сокращать результат WHERE

-- Применяй фильтры как можно раньше
WHERE condition BEFORE JOIN, не AFTER

4. Использовать партиционирование

-- На больших таблицах партиционировать:
PARTITION BY RANGE (user_id)

5. Кэширование вместо JOIN-ов

# Вместо 5 JOIN-ов в SQL,
# загрузить в app layer и JOIN в памяти
users = cache.get_users()  # Redis
orders = db.get_orders()   # Кэшированный запрос
# JOIN в памяти (намного быстрее)

Когда JOIN-ы становятся проблемой

Красный флаг:

• Запрос с 5+ JOIN-ами без WHERE
• Один JOIN занимает > 1 сек
• EXPLAIN показывает Sequential Scan на таблице с 1M+ записей
• Join Condition использует функции вместо простого поля

Совет System Analyst

1. Количество JOIN-ов < 10 обычно OK, если правильно индексировано
2. Размер результата более важен, чем количество JOIN-ов
3. Всегда используй EXPLAIN ANALYZE перед оптимизацией
4. Индексы на FK — первая оптимизация
5. Фильтр WHERE как можно раньше — сокращай объём данных
6. Денормализация (кэш) иногда быстрее 5 JOIN-ов
7. N+1 query problem хуже, чем один большой JOIN

Правило: Один хорошо оптимизированный JOIN с индексом быстрее, чем 5 JOIN-ов без индексов.