Вы добавили индекс по created_at, ожидая ускорить SELECT * FROM orders ORDER BY created_at DESC LIMIT 50, но EXPLAIN всё равно показывает Seq Scan и Sort. Какой вывод самый безопасный?

AПланировщик считает текущий путь дешевле по оценкам cost: проверять селективность, статистику и форму запроса через EXPLAIN
BПланировщик Postgres игнорирует индекс по столбцу даты, если в запросе нет условия WHERE с фильтрацией строк
CИндекс по полю created_at применяется только при операциях записи, а на запросах чтения план идёт через Seq Scan
DНаличие LIMIT 50 в запросе блокирует использование индексов и переключает план на чтение всей таблицы через Seq Scan
Правильный ответ. То, что индекс не выбран, не означает, что он бесполезен — это решение планировщика в конкретных условиях.

Разбор

Планировщик сравнивает альтернативы и выбирает то, что кажется дешевле по оценкам cost/rows. Индекс мог не подойти из‑за формы запроса, из‑за того, что нужно прочитать слишком много строк, или из‑за неактуальной статистики. EXPLAIN помогает увидеть факт: какой план выбран и где узлы Sort/Seq Scan, — а дальше уже искать причину и варианты переписывания запроса.

Проверь себя · 1/3разбор после ответа
В EXPLAIN вашего отчёта видно, что выполняется Sort по created_at на очень большом наборе строк. Какое действие чаще всего помогает уменьшить работу сортировки?
Тренировать SQL в Telegram

Ещё вопросы по теме «EXPLAIN и оптимизация»