сеньорчикОткрыть в Telegram
← вся теориятеория к собесу · Базы данных в Python

Проблема N+1 в ORM

N+1: самый частый тормоз на списках

N+1 - вопрос-детектор: почти любой продовый ORM-код рано или поздно его словит, и собес проверяет, умеешь ли ты его увидеть, диагностировать и починить правильным инструментом, а не костылём-кэшем. Ошибка тут - прямой удар по латентности списков.

Типовые формулировки: «что такое N+1 и как его найти?», «как чинить - кэшем или eager-загрузкой?», «joinedload или selectinload».

Механика и диагностика

N+1: один запрос достаёт N строк, а затем на каждую при обращении к связи уходит ещё запрос - итого N+1 запрос. В коде цикл выглядит невинно, поэтому в глаза не бросается, а на списке из 500 элементов это 501 запрос к БД.

Диагностика - включить лог SQL (echo у движка или логирование): сразу видно запрос на каждый элемент цикла. Правило: N+1 не виден в коде, но очевиден в ЧИСЛЕ запросов, поэтому смотри лог, а не только питон.

// Кэшировать каждый мелкий запрос вместо eager-загрузки это маскировка N+1, а не устранение: запросов столько же, просто часть из кэша.

N+1
1 запрос списка + по запросу на связь каждой строки
eager loading
подгрузить связь заранее одним-двумя запросами

Лечение: eager по типу связи

Лечат жадной загрузкой связи ЗАРАНЕЕ. selectinload делает второй SELECT ... IN и хорош для коллекций - он не раздувает строки. joinedload делает JOIN и хорош для «многие к одному». Выбор диктует кардинальность связи, а не привычка.

Почему нельзя везде joinedload: на «один ко многим» он декартово размножает строки родителя по числу детей - растут и объём переданных данных, и работа по дедупу в Python. Для коллекций это как раз selectinload. И select_related/joinedload не решает ЛЮБОЙ N+1: для коллекций нужен prefetch/selectinload.

// В Django те же две стратегии называются select_related (JOIN) и prefetch_related (второй запрос) - механика идентична.

# 501 запрос -> 2 запроса
select(Order).options(selectinload(Order.items))
декартово раздувание
JOIN коллекции множит строки родителя

Как отвечать: «Как найти и починить N+1?»

Сначала найти: включаю лог SQL и смотрю на число запросов - если на список из N элементов летит N с лишним однотипных селектов, это N+1 от ленивой загрузки связи в цикле. В коде он не виден, только в логе. Чиню жадной загрузкой заранее, а не кэшем: кэш просто прячет те же запросы. Инструмент выбираю по связи - для коллекции selectinload, он делает один второй SELECT ... IN; для «многие к одному» joinedload одним JOIN. joinedload на коллекции сознательно не беру: он декартово раздувает строки родителя. В итоге 501 запрос сводится к двум.

Дан полный цикл - диагностика логом, отказ от костыля-кэша, выбор стратегии по связи и конкретный результат; ответ инженера, который это чинил, а не читал.

На чём валят

  • −Кэшировать каждый мелкий запрос вместо eager-загрузки - маскировка N+1, а не устранение.
  • −Считать, что joinedload/select_related решает любой N+1 - для коллекций нужен selectinload/prefetch.
  • −Не смотреть лог SQL: N+1 не виден в коде, но очевиден в числе запросов.
  • −joinedload на «один ко многим»: декартово раздувание строк родителя вместо экономии.

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 11, остальные разбираются в тренажёре.

  1. #n_plus_one1 / 5
    Цикл по авторам печатает число их книг, а в логе SQL — запрос на каждого автора:
    authors = session.scalars(
    select(Author)).all()
for a in authors:
    print(a.name, len(a.books))
    Причина?
    A)select(Author) без фильтра сам порождает N подзапросов
    B)len() заставляет пересчитывать всю таблицу книг заново
    C).all() открывает по соединению с базой на каждый элемент
    D)Ленивая a.books грузится отдельным запросом на итерации
    показать ответ и разбор
    +D)Ленивая `a.books` грузится отдельным запросом на итерации

    // разбор: Первый запрос достаёт авторов, но связь books ленивая: на каждой итерации обращение a.books шлёт отдельный SELECT — вот и запрос на автора (N+1). Лечение: заранее подгрузить связь через selectinload(Author.books) в исходном запросе.

  2. #n_plus_one2 / 5
    Чем лечат N+1 в SQLAlchemy?
    A)Переносом всех связей в отдельную таблицу-справочник заранее
    B)Жадной загрузкой связи заранее (selectinload/joinedload)
    C)Кэшированием результата каждого мелкого запроса в Redis
    D)Увеличением размера пула соединений под нагрузку приложения
    показать ответ и разбор
    +B)Жадной загрузкой связи заранее (selectinload/joinedload)

    // разбор: N+1 устраняют жадной загрузкой: selectinload (второй запрос SELECT ... IN — хорош для коллекций) или joinedload (JOIN — хорош для «многие к одному»). Указываешь стратегию в запросе, и связь подгружается наперёд одним-двумя запросами вместо N.

  3. #n_plus_one3 / 5
    Почему joinedload на коллекции «один ко многим» может ударить по производительности?
    A)joinedload открывает отдельное соединение под каждую связь
    B)JOIN размножает строки родителя по числу детей
    C)joinedload грузит вообще все связи модели без разбора
    D)joinedload полностью игнорирует индексы по внешним ключам
    показать ответ и разбор
    +B)JOIN размножает строки родителя по числу детей

    // разбор: joinedload тянет связь тем же запросом через JOIN: для «один ко многим» каждая строка родителя дублируется по числу детей — результат раздувается (декартово), растёт объём передаваемых данных и работа по дедупликации. Для коллекций обычно предпочитают selectinload.

  4. #n_plus_one4 / 5
    Страница показывает 50 постов, для каждого — имя автора. В логах 51 SELECT. Что за проблема?
    A)База медленно отвечает на один запрос из-за высокой нагрузки на сервер
    B)Запрос вернул на 50 строк больше, чем ожидал разработчик при написании кода
    C)N+1: один запрос за посты плюс по одному за автора каждого
    D)Пул соединений исчерпан, и база открывает по новому коннекту на каждый пост
    показать ответ и разбор
    +C)N+1: один запрос за посты плюс по одному за автора каждого

    // разбор: Классический N+1: один запрос достаёт 50 постов, а обращение к post.author в цикле (вывод имени) порождает по отдельному SELECT на каждого — итого 1+50=51 round-trip. На больших списках это лавина запросов и резкая деградация. Лечится eager-загрузкой (selectinload/joinedload) или JOIN, чтобы авторы пришли за один-два запроса.

  5. #n_plus_one5 / 5
    Чем joinedload отличается от selectinload при устранении N+1?
    A)selectinload работает только с внешними ключами, а joinedload — только с many-to-many
    B)joinedload тянет связь одним JOIN, selectinload — вторым запросом IN по собранным id
    C)Это два имени одной стратегии: разницы в генерируемом SQL между ними нет никакой
    D)joinedload делает несколько запросов, а selectinload обходится ровно одним JOIN
    показать ответ и разбор
    +B)joinedload тянет связь одним JOIN, selectinload — вторым запросом IN по собранным id

    // разбор: Обе — eager-стратегии. joinedload подтягивает связь тем же запросом через JOIN: одна поездка, но на коллекциях дублирует строки родителя и может раздувать результат. selectinload делает второй запрос: собирает id родителей и грузит связанное через WHERE ... IN (...). Для коллекций (один-ко-многим) обычно предпочитают selectinload, для many-to-one — часто joinedload.

дальше

Теорию прочитали. Навык ставится повторением

В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.

Открыть тренажёрВся тема: Базы данных в Python
читать дальше