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