Какие проблемы могут возникнуть при использовании left join с двойными join

Что проверяют

Понимаете ли вы, как соединения множат строки, и замечаете ли это в SQL, который генерирует EF Core. Следом обычно спрашивают про Include нескольких коллекций и AsSplitQuery.

Как отвечать

Сначала SQL:

• декартово произведение: Customers LEFT JOIN Orders LEFT JOIN Tickets, где заказы и обращения независимо привязаны к клиенту. 5 заказов и 6 обращений дают 30 строк на клиента, суммы завышаются. Решение: агрегировать в подзапросах до соединения;
• фильтр в WHERE: условие на правую таблицу в WHERE выкидывает строки с NULL и превращает LEFT JOIN в INNER. Фильтр правой стороны ставится в ON;
• смешанная цепочка: LEFT JOIN к B, а за ним INNER JOIN к C по колонке B отрезает всё, где B не нашлось;
• NULL в агрегатах: COUNT(*) считает пустую строку клиента без заказов, COUNT(o.Id) нет.

Теперь EF Core:

• Include двух коллекций: .Include(c => c.Orders).Include(c => c.Tickets) по умолчанию собирается одним запросом с тем самым декартовым произведением, и EF Core пишет об этом предупреждение в лог. AsSplitQuery() разбивает загрузку на отдельные запросы, глобально это включает UseQuerySplittingBehavior(QuerySplittingBehavior.SplitQuery). Цена: несколько обращений к базе и без транзакции нет согласованного снимка данных;
• левое соединение в LINQ: классика это GroupJoin плюс SelectMany с DefaultIfEmpty(), в .NET 10 появился отдельный оператор LeftJoin;
• материализация NULL: проекция o.Total в decimal для клиента без заказов рискует упасть с InvalidOperationException. Приводите явно к decimal?;
• Dapper: при multi-mapping дубли родителя приходится схлопывать самому, через Dictionary по ключу.

Где спотыкаются

Добавляют Distinct() и считают, что проблема ушла, хотя суммы по-прежнему посчитаны по размноженным строкам.

Включают AsSplitQuery везде подряд. Для одной коллекции одиночный запрос обычно быстрее, а разделение даёт лишние обращения к базе.

Проверяют запрос на данных, где у каждого клиента по одному заказу. Размножение видно только на реалистичных объёмах, поэтому смотрите сгенерированный SQL через ToQueryString().