N+1: одна логическая операция, много round-trip''''ов

Страница медленная — 800 мс. CPU flame graph в порядке, широких функций нет. Свен открывает DB query log и считает 51 запрос на один page load. Профайлер не врал; bottleneck не в одной функции. Он распределён по 51 маленькому round-trip’у.

Что такое N+1

Пользователь просит «покажи список заказов с именами клиентов». ORM выполняет один запрос на orders, потом по одному на каждый order для fetch клиента — 1 + N запросов. На 50 заказах — 51 DB round-trip на один рендер.

Каждый round-trip платит сетевой latency (1–5 мс intra-DC, 10–50 мс cross-region) плюс query-overhead. Страница, которая должна делаться за 20 мс, делается за 500 мс — и инженер не найдёт проблему в CPU-профиле, потому что цена распределена по многим быстрым вызовам. Ни одна функция не медленная.

Почему ORM производит N+1 по умолчанию

Object-relational mapper’ы выставляют модель, где каждый объект имеет relationships, доступные как обычные свойства. order.customer читается как обычный атрибут; под капотом ORM триггерит запрос, если customer ещё не загружен. Это называется lazy loading — удобно, не нужно объявлять заранее, что нужно, — но это источник N+1.

Цикл по 50 заказам, чтение order.customer.name на каждом — ORM стреляет 50 запросами без того, чтобы ты написал 50 запросов.

Метафора кладовой

Готовишь пасту, нужны чеснок, масло, соль и базилик:

• Вариант A (batch): пойти в кладовую один раз, взять все четыре, вернуться. Один trip.
• Вариант B (N+1): пойти за чесноком, вернуться; пойти за маслом, вернуться; пойти за солью, вернуться; пойти за базиликом, вернуться. Четыре trip’а.

Та же работа — четыре trip’а против одного. Паттерн N+1 — вариант B. Фикс — вариант A: сократить прогулки.

Единица цены — round-trip: время от момента, когда код просит данные, до момента, когда данные в руках. RTT, query parse, planner overhead, lock acquisition, result encoding — всё платится за каждый round-trip. Один запрос на 100 строк платит раз; 100 запросов платят 100 раз.

Конкретный пример

// Код ORM, который выглядит безобидно:
const orders = await Order.findAll({ where: { userId } });
for (const order of orders) {
  const customer = await order.getCustomer(); // один запрос на каждый order
  render(order, customer);
}

// Query log:
// SELECT * FROM orders WHERE user_id = 42 LIMIT 50      — 1 запрос
// SELECT * FROM customers WHERE id = 1                   — 1 запрос
// SELECT * FROM customers WHERE id = 2                   — 1 запрос
// ...
// SELECT * FROM customers WHERE id = 50                  — 1 запрос
// Итого: 51 запрос × ~15 мс RTT = 765 мс

Фикс в Prisma и большинстве ORM — одно слово, include:

const orders = await prisma.order.findMany({
  where: { userId },
  include: { customer: true },
});
// Теперь: 2 запроса — один на orders, один на всех customers через IN (...)
// Итого: ~20 мс

Вложенный N+1: проблема множится

Дашборд рендерит команды → проекты → участников. Наивный ORM:

• 1 запрос на команды
• N запросов на проекты (один на команду)
• N×M запросов на участников (один на проект)

С 10 командами × 5 проектов × 8 участников: 1 + 10 + 50 = 61 запрос. Фикс nested eager loading: 3 запроса. Рендер падает с 1,5 с до 80 мс.