Есть запрос SELECT * FROM events WHERE user_id = 42 ORDER BY created_at DESC LIMIT 50. Какой вариант индекса чаще всего помогает, чтобы избежать Sort и быстро получить первые строки?
AИндекс по
(created_at): чтение строк уже в нужном порядке, фильтр по user_id после Index ScanBИндекс по
(user_id): фильтрует строки пользователя, далее Sort на 50 итоговых строках допустимCИндекс по
(user_id, created_at): Index Scan сразу в нужном порядке без отдельного шага SortDИндекс по
(created_at, user_id): покрывает оба столбца, даёт Index Only Scan без таблицыПравильный ответ. Составной индекс может одновременно поддержать фильтр и порядок сортировки.
Разбор
Когда запрос фильтрует по user_id и сортирует по created_at, составной индекс по (user_id, created_at) часто позволяет читать нужный диапазон уже упорядоченным. Тогда планировщик может выбрать Index Scan и применить Limit почти сразу, без отдельного шага Sort. Это типичный паттерн для «последние N событий пользователя».
Проверь себя · 1/3разбор после ответа
Как удобнее интерпретировать дерево
EXPLAIN, чтобы понять, откуда берутся строки и где тратятся ресурсы запроса?Ещё вопросы по теме «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 и оптимизация» →