Вы смотрите EXPLAIN запроса для дашборда и видите фрагмент: Sort → Limit. При этом сортировка происходит по миллионам строк. Где с наибольшей вероятностью узкое место?
AВ узле
Limit, потому что он «режет» результат.BВ самом операторе
SELECT, потому что он всегда самый дорогой.CВ сетевой передаче результата клиенту.
DВ узле
Sort, потому что чтобы применить ORDER BY, базе нужно упорядочить большой набор до Limit (если нет подходящего индекса).Правильный ответ. Часто дорого не
LIMIT, а сортировка перед ним.Разбор
Если нет индекса, который может отдать строки уже в нужном порядке, база вынуждена выполнять Sort для всего набора, а потом брать первые строки через Limit. Поэтому для ускорения обычно пытаются уменьшить объём данных до сортировки (более селективный WHERE) или добавить индекс под ORDER BY.
Проверь себя · 1/3разбор после ответа
На большой таблице
events запрос SELECT * FROM events ORDER BY created_at DESC LIMIT 100 неожиданно работает быстро. Какое объяснение наиболее вероятно при наличии индекса по created_at?Ещё вопросы по теме «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 и оптимизация» →