Сначала определяют, какие связи реально будут прочитаны: одиночные загружают select_related, коллекции — prefetch_related. Затем измеряют число запросов и объём данных на полном сценарии рендера.
Вы хорошо описали диагностику через EXPLAIN ANALYZE и причины выбора типа сканирования. А как бы вы выбрали связанные объекты в Django ORM, чтобы минимизировать количество запросов к базе?
Сначала определяют, какие связи реально будут прочитаны: одиночные загружают select_related, коллекции — prefetch_related. Затем измеряют число запросов и объём данных на полном сценарии рендера.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Сначала определяют, какие связи реально будут прочитаны: одиночные загружают select_related, коллекции — prefetch_related. Затем измеряют число запросов и объём данных на полном сценарии рендера.
Например, список заказов с одним customer обычно выигрывает от JOIN, а позиции каждого заказа — от отдельной предварительной загрузки коллекции. Для фильтрованного prefetch используют явную настройку и не предполагают, что любой последующий filter возьмёт данные из кеша. Только минимальное число SQL не является целью: огромный JOIN или загрузка всех связей может быть хуже нескольких небольших запросов. Проверять надо и память, и задержку.