На большой таблице 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 не нужна или становится значительно дешевле. Поэтому одинаковый запрос без индекса может быть на порядки медленнее.
Можно заниматься бесплатно
Готовим вопросы…
Три вопроса по теме этой страницы, с объяснениями.
Ещё вопросы по теме «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 и оптимизация» →