🗄️ SQL и базы данных · 20 вопросов · ~42 мин · ⏱ Таймер 42:00 · Сложный · 👥 1 прошёл

Индексы

Индекс оценивается по конкретной нагрузке, а не по принципу «чем больше, тем быстрее». В тесте нужно выбрать B-tree для сравнения и порядка, понять левую часть составного индекса, отличить ключевые столбцы от INCLUDE, увидеть пользу частичного и индексированного выражения, а также учесть цену вставок, размер и низкую избирательность.

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выбери один ответ из четырёх. В тесте 20 вопросов и 42 минут. После завершения откроются общий процент, четыре тематические шкалы, правильные ответы и разбор каждого задания.

Вопрос 1 из 20

Для какого условия B-tree особенно естественен?

WHERE document @@ to_tsquery('sql') WHERE id = 42 WHERE geom && polygon WHERE payload @> jsonb_build_object(...)

Вопрос 2 из 20

Может ли B-tree помогать диапазону created_at?

SELECT * FROM events WHERE created_at >= TIMESTAMP '2026-07-01';

Да, B-tree поддерживает сравнения и диапазоны Нет: B-tree пригоден лишь для точного равенства, но не для <, > или BETWEEN B-tree помогает диапазону только после GROUP BY по тому же столбцу Только если дата хранится text

Вопрос 3 из 20

Почему индекс не гарантирует, что планировщик его выберет?

EXPLAIN SELECT * FROM users WHERE active = true;

Индекс выбирается по фиксированному порогу числа строк, одинаковому для всех таблиц Планировщик может оценить Seq Scan как более дешёвый Новый индекс нельзя использовать до отдельного ANALYZE и нового подключения Планировщик обязан выбрать индекс, если столбец индекса упомянут в WHERE

Вопрос 4 из 20

Что делает индекс на lower(email)?

CREATE INDEX users_email_lower_idx ON users (lower(email));

Ускоряет любой LIKE с начальным % Индекс выражения автоматически делает lower(email) уникальным без UNIQUE Позволяет искать по тому же выражению lower(email) Меняет данные email на нижний регистр

Вопрос 5 из 20

Когда возможен index-only scan в общих чертах?

Когда нужные запросу столбцы доступны из индекса и видимость строк позволяет не обращаться к heap Когда в таблице есть PRIMARY KEY, даже если запрос читает другие столбцы Только для COUNT(*) без фильтра и без проверки видимости строк Когда таблица целиком помещается в shared_buffers, независимо от состава индекса

Вопрос 6 из 20

Какой запрос лучше соответствует индексу (tenant_id, created_at)?

WHERE created_at >= CURRENT_DATE - 7 WHERE tenant_id=10 AND created_at >= CURRENT_DATE - 7 WHERE status='new' WHERE lower(email)='a@b'

Вопрос 7 из 20

Почему запрос только по created_at может использовать такой индекс хуже?

ORDER BY created_at автоматически делает второй столбец ведущим ключом B-tree Планировщик начнёт единый диапазон с нужной даты, даже без условия по tenant_id Планировщик переставит столбцы составного индекса и начнёт поиск с created_at Без ограничения ведущего tenant_id данные разных арендаторов перемешаны по диапазонам второго ключа

Вопрос 8 из 20

Что означает INCLUDE (amount)?

CREATE INDEX orders_idx ON orders (customer_id, created_at) INCLUDE (amount);

amount хранится для покрытия, но не служит ключом поиска amount автоматически суммируется amount участвует в поисковой навигации наравне с ключами amount становится UNIQUE

Вопрос 9 из 20

Для WHERE a=1 ORDER BY b какой индекс вероятнее всего полезен?

CREATE INDEX ON t(c); CREATE INDEX ON t(b,a); CREATE INDEX ON t(a,b); CREATE INDEX ON t(a) INCLUDE (b);

Вопрос 10 из 20

Что происходит с полезностью последующих ключей после диапазона по первому столбцу?

Их способность сузить единый непрерывный диапазон обычно ограничивается; детали проверяют планом Ключи после диапазона физически исчезают из индекса для этого запроса Диапазон преобразуется в равенство После диапазона все последующие столбцы составного индекса становятся UNIQUE

Вопрос 11 из 20

Когда частичный индекс особенно уместен?

CREATE INDEX tasks_open_idx ON tasks (created_at) WHERE status='open';

Когда WHERE отсутствует Когда нужно индексировать вообще все строки дважды Когда таблица состоит из одной строки Когда запросы часто ищут редкие строки со status = 'open'

Вопрос 12 из 20

Какой запрос может напрямую использовать условие этого частичного индекса?

CREATE INDEX tasks_open_idx
ON tasks (created_at)
WHERE status = 'open';

WHERE created_at < now() WHERE status IN ('open','done') WHERE status='open' AND created_at < now()-interval '1 day' WHERE status='closed'

Вопрос 13 из 20

Почему индекс на boolean active часто мало полезен, если true у 95% строк?

Условие малоизбирательно и возвращает почти всю таблицу PostgreSQL не разрешает создавать B-tree по boolean-столбцам B-tree по boolean делит таблицу на два компактных диапазона, поэтому высокая доля true не мешает Hash-индекс устраняет низкую селективность boolean и потому подходит лучше B-tree

Вопрос 14 из 20

Какой индекс соответствует WHERE lower(email)=lower($1)?

CREATE INDEX ON users(email); CREATE INDEX ON users(length(email)); CREATE INDEX ON users(id); CREATE INDEX ON users(lower(email));

Вопрос 15 из 20

Почему ведущий шаблон LIKE '%term' обычно не использует обычный B-tree как префиксный поиск?

% в начале не оставляет фиксированной начальной границы строки B-tree хранит лишь числа и даты, но не строковые значения Оператор LIKE полностью исключает использование любого индекса Проблема только в том, что term короче минимальной длины ключа B-tree

Вопрос 16 из 20

Что происходит при INSERT в таблицу с пятью индексами?

Нужно обновить все применимые индексы, что добавляет работу и записи При вставке обновляется только один индекс, выбранный планировщиком для будущего чтения INSERT меняет только heap, а все индексы обновляются позже во время VACUUM Записи во все индексы откладываются до ближайшего checkpoint

Вопрос 17 из 20

Когда UPDATE неиндексированного столбца всё равно может затрагивать индексы косвенно в PostgreSQL?

Любой UPDATE создаёт новые записи во всех индексах, даже если HOT возможен Индексы не затрагиваются, пока изменяемый столбец не входит ни в один из них Косвенная стоимость появляется только после ручного REINDEX Детали зависят от возможности HOT-обновления и наличия места; не каждое обновление одинаково дёшево

Вопрос 18 из 20

Почему два индекса (a) и (a,b) могут частично дублировать друг друга?

При записи PostgreSQL физически объединяет оба определения и хранит одну общую структуру Составной индекс часто способен обслужить поиск по ведущему a Индексы (a) и (a,b) имеют одинаковый размер, порядок и стоимость для любого запроса После создания (a,b) сервер перестаёт обслуживать отдельный индекс (a)

Вопрос 19 из 20

Почему CREATE INDEX на большой рабочей таблице требует плана выполнения работ?

Обычный CREATE INDEX блокирует только чтение, но не конкурирующие записи Режим CONCURRENTLY не требует дополнительного времени, места и повторных проходов Индекс может занять место, время и влиять на конкурентные операции; режим создания выбирают осознанно Достаточно проверить свободное место; влияние на блокировки и репликацию отсутствует

Вопрос 20 из 20

Как понять, что индекс действительно нужен?

Индекс нужен для каждого столбца, который хотя бы иногда встречается в WHERE Индекс полезен, если оценочная стоимость снизилась в одном искусственном запросе По повторяющейся нагрузке, EXPLAIN ANALYZE, избирательности и измеренному улучшению с учётом цены записи Индекс оправдан, если запрос длинный и содержит несколько условий, даже без измерений

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу