Базы данных
Индексы: тест на припоминание
Припоминание сильнее перечитывания. На каждый промпт скажи или запиши полный ответ по памяти, прежде чем открыть модельный — именно усилие припоминания закрепляет leading-column rule и Visibility Map.
Восстанови ключевые механизмы юнита — leading-column rule, когда partial бьёт full, что запускает index-only scan, как выбрать тип индекса и самые частые production-сбои — не подглядывая в уроки.
- 01Почему composite index (a, b, c) помогает WHERE a = ? и WHERE a = ? AND b = ?, но не WHERE b = ? — и какое единственное правило дизайна из этого следует?
- 02Когда partial index выигрывает у полного индекса и что должен удовлетворять запрос, чтобы его использовать?
- 03Какие два условия должны выполняться одновременно, чтобы index-only scan избежал heap fetches, и как держать их истинными в production?
- 04Назови, когда ты выйдешь за B-tree ради GIN, GiST, BRIN и pgvector HNSW, и какую цену несёт каждый.
- 05Почему foreign-key колонки — повторяющаяся production-ловушка и какое правило?
- 06Перечисли семь production-сбоев индексов и единственный диагностический приём, вскрывающий каждый.
Если ты смог восстановить каждый ответ по памяти, ты держишь хребет юнита: composite используется только от ведущего префикса, поэтому проектируй его вокруг всегда присутствующего фильтра и заверши ORDER BY-колонками; partial-индексы сжимаются пропорционально горячему подмножеству и пропускают записи холодных строк; index-only scan нужны и полное покрытие (ключ + INCLUDE), и свежая Visibility Map (VACUUM); тип индекса должен подходить форме данных; FK-колонки никогда не индексируются автоматически; а семь сбоев всплывают под одним диагностическим приёмом — EXPLAIN (ANALYZE, BUFFERS) на реальном запросе.