Семейства фиксов: JOIN, IN, preload и DataLoader

В query-логе подтверждён N+1: 50 запросов к customers на одной странице заказов. Есть четыре способа исправить это, и у каждого свои tradeoff’ы. Выбрать неподходящий для вашей формы данных — значит сделать хуже.

Четыре семейства фиксов

1. JOIN — один запрос, один round-trip

Получить родителя и потомков в одном SQL-запросе через JOIN:

SELECT o.*, c.name AS customer_name
FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE o.user_id = 42
LIMIT 50;

Один round-trip. База данных возвращает всё слитым в один результирующий набор.

Tradeoff: для связей один-ко-многим результирующий набор дублирует колонки родителя для каждой строки-потомка. Пятьдесят заказов с пятью позициями каждый дают 250 строк, где 200 повторяют одни и те же колонки заказа. Сетевой трафик и стоимость парсинга в ORM могут перекрыть экономию на round-trip. JOIN лучше всего работает для один-к-одному или небольшого один-ко-многим (1–5 потомков на родителя).

2. IN — два запроса, без дублирования

Два round-trip’а: сначала получить родителей, затем получить всех потомков через WHERE id IN (...):

-- Запрос 1: получить все заказы
SELECT * FROM orders WHERE user_id = 42 LIMIT 50;

-- Запрос 2: получить всех customers для этих заказов
SELECT * FROM customers WHERE id IN (1, 2, 3, ..., 50);

Никакого дублирования строк. Родительский результат — 50 строк; результат потомков — до 50 строк. Каждая строка данных появляется ровно один раз.

Tradeoff: IN-список имеет практические ограничения. Postgres обрабатывает 10 000+ элементов с растущей стоимостью планировщика; MySQL имеет жёсткое ограничение по max_allowed_packet. Для большинства пагинаций (10–1000 элементов) IN — правильный выбор по умолчанию для один-ко-многим.

3. Preload / eager loading — директива ORM

Все крупные ORM предоставляют директиву, которая заранее объявляет, какие связи загружать. ORM сам выбирает JOIN или IN внутри:

# Rails — .includes выбирает стратегию
Order.where(user_id: current_user).includes(:customer).limit(50)

# Django
Order.objects.filter(user=request.user).select_related('customer')[:50]

# SQLAlchemy
session.query(Order).options(selectinload(Order.customer)).filter_by(...).limit(50)

# Prisma
prisma.order.findMany({ where: {...}, include: { customer: true } })

Все эти варианты дают 2 запроса вместо 51. Вы объявляете намерение; ORM оптимизирует тактику.

Tradeoff: если объявлять preload слишком агрессивно — загружать связи, которые запрос никогда не использует — вы тратите I/O впустую. Объявляйте только то, что нужно текущему запросу.

4. DataLoader — батчинг в рамках запроса

DataLoader (Facebook, 2015) накапливает ID-шники в очереди на протяжении всего запроса и выполняет один батч-запрос, когда event loop переходит к следующему тику:

// Создаётся один раз на запрос
const userLoader = new DataLoader(async (ids) => {
  const users = await db.user.findMany({ where: { id: { in: ids } } });
  return ids.map(id => users.find(u => u.id === id));
});

// Вызвать из любого места в запросе — каждый вызов ставит id в очередь
const user = await userLoader.load(orderId);

DataLoader даёт три свойства: (1) автоматический батчинг — множество вызовов load(id) становятся одним запросом, (2) автоматическое кэширование — повторный load(id) в том же запросе возвращает кэшированный результат без повторного запроса, (3) request scope — кэш ограничен запросом, поэтому устаревшие данные не утекают между запросами.

Tradeoff: DataLoader требует async / event-loop runtime. Добавляет сложность кэширования и небольшую latency batch-window (обычно менее 1 мс). Это правильный инструмент, когда потребности в данных разбросаны по множеству несвязанных путей в одном запросе — канонический пример — GraphQL-резолверы.

Выбор по кардинальности

Правило большого пальца:

• Один-к-одному → JOIN. Нет дублирования. Один trip.
• Один-ко-многим (небольшой fan-out) → preload. ORM выбирает JOIN внутри. Просто в написании.
• Один-ко-многим (большой fan-out) → IN-based selectinload. Избегает раздувания result set.
• Multi-source или GraphQL → DataLoader. Батчит из несвязанных путей кода.

Практический пример: вложенный eager load

# Rails вложенный eager load:
User.find(42).projects.includes(tasks: :comments).limit(50)
# Даёт:
#   SELECT * FROM projects WHERE user_id = 42 LIMIT 50
#   SELECT * FROM tasks WHERE project_id IN (1, 2, ..., 50)
#   SELECT * FROM comments WHERE task_id IN (...)
# 3 запроса вместо 1 + 50 + 250 = 301

# Эквивалент на Django:
Project.objects.filter(user=user).prefetch_related('tasks__comments')[:50]

# SQLAlchemy:
session.query(Project).options(
    selectinload(Project.tasks).selectinload(Task.comments)
).filter_by(user_id=42).limit(50)