Вы считаете число заказов по таблице orders, но добавили JOIN к таблице order_items и получили подозрительно большой результат. В EXPLAIN оценка rows после соединения стала намного больше, чем rows на входе. Что это чаще всего означает?
A
EXPLAIN сообщает точное время выполнения, и оно будет «намного больше».BСоединение
JOIN умножает строки (связь один-ко-многим), и агрегат вроде COUNT(*) может считать позиции, а не заказы; нужно проверить логику (COUNT(DISTINCT orders.id) или агрегация до JOIN).CИндекс обязательно отсутствует и без него корректность невозможна.
DЭто признак того, что база «потеряла» первичный ключ.
Правильный ответ. План помогает заметить «размножение» строк из‑за
JOIN и связать это с корректностью метрики.Разбор
Если после JOIN ожидаемое количество строк резко растёт, это часто нормальное следствие отношения один-ко-многим. Но для аналитики важно, что агрегат может начать считать не то (например, позиции вместо заказов). EXPLAIN не докажет корректность сам по себе, но он подскажет, где возникает кратность и где стоит пересмотреть агрегацию.
Проверь себя · 1/3разбор после ответа
В выводе
EXPLAIN вы видите узел Seq Scan on orders. Что это обычно означает?Ещё вопросы по теме «EXPLAIN и оптимизация»
- Вы хотите добавить новый запрос в дашборд и боитесь, что он сильно нагрузит базу, потому что таблица `events` очень большая. Что дает запуск `EXPLAIN` для этого запроса?
- В выводе `EXPLAIN` вы видите узел `Seq Scan on orders`. Что это обычно означает?
- В плане `EXPLAIN` для запроса по пользователю вы видите `Index Scan using orders_user_id_idx on orders`. Какой вывод наиболее корректен?
- На большой таблице `events` запрос `SELECT * FROM events ORDER BY created_at DESC LIMIT 100` неожиданно работает быстро. Какое объяснение наиболее вероятно при наличии индекса по `created_at`?
- Есть индекс по `orders.created_at`, но `EXPLAIN` для фильтра `WHERE date(created_at) = current_date` показывает `Seq Scan`. Почему это часто происходит?
- Все вопросы по «EXPLAIN и оптимизация» →