Базы данных
Индексы: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту об индексах — leading-column rule, partial и covering индексы, index-only scan и Visibility Map, выбор типа индекса и production-сбои.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Ни один не про заучивание определений — каждый отражает решение по проектированию или инцидент, который ты взвешиваешь под реальной нагрузкой запросов, где неправильный индекс стоит места на диске, write-пропускной способности или ночного пейджа.
Цель
Убедись, что связываешь анатомию B-tree, leading-column rule, partial и covering индексы, index-only scan, выбор типа индекса и production-сбои — тот синтез, к которому вели семь уроков.
Викторина
Completed
У multi-tenant дашборда есть индекс (workspace_id, status, created_at). Новый аналитический запрос делает WHERE status = 'pending' ORDER BY created_at DESC без фильтра по workspace_id и получает sequential scan. Как чинить, не нарушая дисциплину дизайна из юнита?
Heads-up Это сломает все существующие tenant-scoped запросы, фильтрующие по workspace_id первым. Composite проектируют под доминирующий запрос, а не перетасовывают один индекс под новый паттерн доступа — добавь второй индекс.
Heads-up Устаревшая статистика даёт неверные оценки строк, а не структурную невозможность использовать индекс. Ни один префикс (workspace_id, status, created_at) не начинается со status, поэтому индекс не даёт точки входа независимо от статистики.
Heads-up В Postgres нет index hints, и индекс не покрывает фильтр только по status — status это вторая ключевая колонка, недостижимая без ведущей workspace_id. Leading-column rule структурно обязателен, это не предпочтение планировщика.
Викторина
Completed
В таблице tasks на 100M строк 80% имеют status = 'done' (дашборд их никогда не читает). Дашборд читает только open и in_progress. Какая стратегия индекса минимизирует и размер, и write-overhead?
Heads-up Полный индекс покрывает все 100M строк, включая 80M done-строк, которые дашборд не читает — он примерно в 5× больше, чем нужно, и каждая запись в done-строку всё равно его поддерживает. Partial-предикат убирает этот расход.
Heads-up 20% от 100M это 20M строк, но дашборд фильтрует дальше (по workspace, по project) до крошечного селективного среза. Partial index по горячему подмножеству — именно то, что нужно планировщику.
Heads-up BRIN хранит min/max по диапазону блоков и помогает только когда данные физически упорядочены по индексируемой колонке. status низкокардинальна и не упорядочена на диске; каждый диапазон блоков охватывает все статусы, так что BRIN не даёт отсечения.
Викторина
Completed
EXPLAIN (ANALYZE, BUFFERS) показывает Index Only Scan с Heap Fetches: 12000 на таблице orders, и запрос медленный, несмотря на правильный covering index. Что происходит и какой устойчивый фикс?
Heads-up Если бы колонок не хватало, узел плана был бы Index Scan, а не Index Only Scan. Index-only scan с heap fetches — это проблема Visibility Map, а не покрытия.
Heads-up INVALID-индекс невидим планировщику — план показал бы Seq Scan, а не Index Only Scan. Тип скана доказывает, что индекс валиден и выбран.
Heads-up Число строк не определяет heap fetches; их определяет бит Visibility Map на страницу. Append-mostly таблица, возвращающая миллионы строк, всё равно может показывать Heap Fetches: 0, если VACUUM держит VM свежей.
Викторина
Completed
DELETE FROM posts WHERE id = 42 с ON DELETE CASCADE занимает 7 минут и всё это время держит блокировки, на схеме posts/comments. В чём корневая причина?
Heads-up posts(id) — это primary key и он уже проиндексирован. Каскад сканирует дочернюю таблицу comments по post_id; именно непроиндексированная ссылающаяся колонка, а не ссылаемая, форсирует O(n)-скан.
Heads-up Индекс на comments(post_id) превращает поиск каскада в index scan. Медлительность — это отсутствующий индекс, а не внутреннее свойство каскадов.
Heads-up VACUUM убирает dead tuples и помогает видимости, но не даёт каскаду способа находить дочерние строки по post_id. Скан чинит только индекс на comments(post_id).
Викторина
Completed
orders.user_id это BIGINT с индексом orders(user_id). Запрос делает SELECT * FROM orders WHERE user_id = '42' (литерал TEXT) и получает Seq Scan. Почему и какой фикс?
Heads-up Bloat замедляет индекс, но не переключает план на Seq Scan для селективного равенства. Причина здесь — приведение типа, отключающее использование индекса; EXPLAIN показывает coercion в фильтре.
Heads-up B-tree прекрасно обрабатывает равенство BIGINT. Проблема в TEXT-литерале, форсирующем приведение колонки на каждой строке, а не в типе индекса.
Heads-up Это обход симптома через индексирование не того. Правильный фикс — отправлять правильный тип, чтобы использовался существующий индекс; не добавляй индекс ради компенсации баги типа в запросе.
Викторина
Completed
Поиск делает WHERE title ILIKE '%invoice%' на таблице в 50M строк и занимает 12 секунд. Запрос — это keyword-поиск по тексту документов. Какой правильный выбор индекса?
Heads-up У ведущего wildcard '%invoice%' нет известного префикса, поэтому B-tree (которому нужен префикс для навигации) не помогает — это всегда O(n). Именно поэтому запрос медленный.
Heads-up HNSW делает семантическую близость и требует embedding-пайплайн на каждый документ и запрос. Для точного keyword-поиска это неправильный и куда более дорогой инструмент; tsvector GIN — дефолт.
Heads-up BRIN суммирует min/max по диапазону блоков для физически упорядоченных числовых или временных данных. Он вообще не умеет отвечать на подстроку или keyword-containment по тексту.
Итог
Сквозная линия юнита — один цикл проектирования: composite используется только от ведущего префикса, поэтому проектируй его вокруг всегда присутствующего фильтра; partial-предикаты урезают индекс по горячему подмножеству до доли полного размера и пропускают записи холодных строк; INCLUDE плюс свежая Visibility Map позволяют index-only scan пропускать heap; тип индекса должен соответствовать форме данных (B-tree для упорядоченных значений, GIN для текста и JSONB, HNSW для семантики); а повторяющиеся сбои — отсутствующий FK-индекс, приведение типа, устаревшая статистика, ведущий wildcard в ILIKE — все сводятся к подгонке индекса под точный вопрос, который задаёт запрос, проверенной через EXPLAIN (ANALYZE, BUFFERS).