В EXPLAIN вашего отчёта видно, что выполняется Sort по created_at на очень большом наборе строк. Какое действие чаще всего помогает уменьшить работу сортировки?
AДобавить
OFFSET 0 в начало выборки, чтобы планировщик пропустил внутреннюю сортировку и сразу читал страницыBУбрать условие
WHERE из запроса, чтобы планировщик выбрал более эффективный путь и задействовал индексCДобавить индекс по полю из
ORDER BY created_at или сократить вход в сортировку селективным WHEREDЗаменить
ORDER BY created_at на GROUP BY created_at: группировка делается без шага сортировки строкПравильный ответ. Сортировка ускоряется, если база может получить строки уже в нужном порядке из индекса.
Разбор
Если план вынужден делать Sort по миллионам строк, это часто главный потребитель ресурсов. Индекс по полю из ORDER BY (или составной индекс под фильтр + порядок) позволяет избежать полной сортировки или существенно её удешевить. Альтернативно можно уменьшить вход в сортировку через более точный WHERE.
Можно заниматься бесплатно
Готовим вопросы…
Три вопроса по теме этой страницы, с объяснениями.
Ещё вопросы по теме «EXPLAIN и оптимизация»
- Вы хотите добавить новый запрос в дашборд и боитесь, что он сильно нагрузит базу, потому что таблица `events` очень большая. Что даёт запуск `EXPLAIN` для этого запроса?
- В выводе `EXPLAIN` вы видите узел `Seq Scan on orders`. Что это обычно означает в плане выполнения запроса?
- В плане `EXPLAIN` для запроса по пользователю вы видите проход по индексу `orders_user_id_idx` для таблицы заказов. Какой вывод наиболее корректен?
- На большой таблице `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 и оптимизация» →