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

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

Разбор

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

Проверь себя · 1/3разбор после ответа
В плане EXPLAIN для запроса по пользователю вы видите Index Scan using orders_user_id_idx on orders. Какой вывод наиболее корректен?
Тренировать SQL в Telegram

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