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

Планы выполнения запросов

Вместо заучивания названий узлов нужно прочитать путь данных: сколько строк ожидал оптимизатор, сколько получил, где появились лишние циклы, почему Seq Scan не всегда плох и как Nested Loop, Hash Join и Merge Join соотносятся с объёмом и доступом к входам. Часть заданий использует сокращённые фрагменты EXPLAIN ANALYZE, похожие на рабочую диагностику.

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

⏱ --:--

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

Вопрос 1 из 20

В каком направлении полезно читать дерево плана для понимания потока строк?

Aggregate
  -> Hash Join
       -> Seq Scan on orders
       -> Hash
            -> Seq Scan on customers

От узлов-источников к потребляющим их родителям От корня к листьям только по стоимости По алфавиту названий узлов Только строку Planning Time

Вопрос 2 из 20

Что означает cost=0.00..120.50?

Seq Scan on orders  (cost=0.00..120.50 rows=5000 width=24)

Число блокировок Точные миллисекунды выполнения Размер таблицы в мегабайтах Оценка цены запуска и получения всех строк

Вопрос 3 из 20

Что означает actual rows=3 loops=100 у внутреннего узла?

Index Scan ... (actual time=0.01..0.02 rows=3 loops=100)

Узел выполнился 3 раза 100 — оценка стоимости Узел вернул всего 3 строки за все вызовы 100 запусков, в среднем по 3 строки за запуск

Вопрос 4 из 20

Почему верхний узел обычно имеет время, включающее работу дочерних узлов?

Он потребляет их результат в рамках своей операции Дочерние узлы выполняются после родителя, поэтому в его интервал не попадают Времена узлов не связаны: EXPLAIN печатает их в произвольном порядке Время родительского узла показывает только его собственную работу без времени детей

Вопрос 5 из 20

Какой параметр помогает увидеть объём данных одной строки плана?

Hash Join  (cost=... rows=10000 width=128)

Planning Time width Filter loops

Вопрос 6 из 20

Всегда ли Seq Scan означает отсутствие полезного индекса?

Seq Scan on countries  (cost=0.00..1.30 rows=30 width=64)

Да: Seq Scan допустим только для запроса без WHERE Да: любой Seq Scan означает, что подходящего индекса в схеме нет Нет, последовательное чтение иногда дешевле индекса Нет: наличие индекса не влияет на план, PostgreSQL использует только последовательное чтение

Вопрос 7 из 20

Почему план мог выбрать Seq Scan для active=true, если true у 98% строк?

B-tree нельзя строить по boolean-столбцам в PostgreSQL Индекс мало сокращает чтение, почти вся таблица всё равно нужна Индекс станет выгодным после добавления ORDER BY active без изменения фильтра Seq Scan выбран потому, что планировщик не учитывает условия WHERE по boolean

Вопрос 8 из 20

Что показывает Index Cond?

Index Scan using orders_customer_idx on orders
  Index Cond: (customer_id = 42)
  Filter: (status = 'paid')

Текст ограничения UNIQUE Условие сортировки результата Условие, использованное для навигации по индексу Фильтр после чтения всех строк таблицы

Вопрос 9 из 20

Когда Bitmap Heap Scan часто уместен?

При чтении почти всей таблицы, когда последовательный проход дешевле При умеренном числе совпадений, которые сначала собираются в bitmap страниц При единичном совпадении по первичному ключу и точном Index Scan В запросе без условий, сортировки и доступных индексов

Вопрос 10 из 20

Что означает Rows Removed by Filter: 900000 при 1000 возвращённых строках?

Seq Scan on events
  Rows Removed by Filter: 900000
  actual rows=1000

Фильтр не выполнялся Запрос вернул 901000 строк 900000 строк удалены из таблицы До фильтра прочитано намного больше кандидатов

Вопрос 11 из 20

Когда Nested Loop особенно хорош?

При FULL JOIN двух больших таблиц независимо от фильтра и индексов Маленький внешний набор и быстрый индексный поиск во внутреннем Когда оба входа огромны, не отфильтрованы и не имеют быстрого поиска по ключу Только для неравенства, которое нельзя проверить индексом или хешированием

Вопрос 12 из 20

Что настораживает в Nested Loop с внутренним Seq Scan loops=50000?

Nested Loop
  -> Seq Scan on outer_t (actual rows=50000 loops=1)
  -> Seq Scan on inner_t (actual rows=2 loops=50000)

Seq Scan внутри выполняется один раз loops — число столбцов Внутренняя таблица может перечитываться огромное число раз Nested Loop автоматически кеширует всю таблицу

Вопрос 13 из 20

Что обычно делает Hash Join по равенству?

Hash Join
  Hash Cond: (o.customer_id = c.id)
  -> Seq Scan on orders o
  -> Hash
       -> Seq Scan on customers c

Ищет каждую строку второго входа только через B-tree индекс Запускает правый подзапрос отдельно для каждой строки левого входа Сортирует оба входа по ключу и затем проходит их синхронно Строит хеш по одному входу и ищет совпадения строк другого

Вопрос 14 из 20

Какой риск у Hash Join при сильно недооценённом большом входе?

Хеш может не поместиться в запланированную память и разбиться на партии с диском Hash Join заменит соединение удалением строк из большего входа При нехватке памяти Hash Join пропустит часть строк без сообщения об ошибке Хеш-таблица автоматически превратится в постоянный индекс и замедлит запись

Вопрос 15 из 20

Что требуется Merge Join в общем случае?

Входы, доступные в подходящем порядке по ключам соединения На правой таблице обязателен hash-индекс, даже если вход уже отсортирован Внешний вход должен содержать ровно одну строку на каждый ключ Обе таблицы должны быть физически записаны на диске в порядке ключа

Вопрос 16 из 20

План оценил rows=10, а фактически получил 100000. Почему это важно?

Index Scan ... (cost=... rows=10 ...) (actual ... rows=100000 loops=1)

Фактическое число строк собирается уже после выполнения и не связано с качеством плана Дальнейший план выбран для неверного объёма Расхождение влияет лишь на оформление EXPLAIN, но не на выбор последующих узлов Такое расхождение означает синтаксическую ошибку, а не проблему статистики

Вопрос 17 из 20

Что стоит проверить первым при большой ошибке оценки после массовой загрузки?

Длину имени индекса и порядок слов в его названии Актуальна ли статистика после загрузки и выполнялся ли ANALYZE Число SELECT в приложении, не проверяя статистику изменённой таблицы Изменение формата вывода EXPLAIN и настроек отображения стоимости

Вопрос 18 из 20

Почему отдельные статистики по country и city могут плохо оценивать условие country='EE' AND city='Tallinn'?

Совместная оценка станет точной только после превращения city в PRIMARY KEY При AND планировщик использует статистику только первого условия, а второе учитывает как постоянную поправку Текстовые значения нельзя оценивать статистикой, поэтому оба условия считаются случайными Столбцы зависимы, а независимое перемножение частот искажает оценку

Вопрос 19 из 20

Где искать первую причину плохого верхнего плана?

В верхнем узле с самой большой итоговой стоимостью, не раскрывая его потомков Только в Planning Time, потому что исполнение не влияет на выбор алгоритма В отсутствии индекса на каждом столбце, встречающемся в тексте запроса В первом снизу узле с крупным расхождением estimated и actual rows

Вопрос 20 из 20

Почему EXPLAIN ANALYZE для изменяющего запроса требует осторожности?

Для UPDATE он показывает фактическое время, но автоматически откатывает изменения Он реально выполняет запрос, поэтому DML может изменить данные без защитной транзакции Он только строит план, но не выполняет изменяющую часть оператора EXPLAIN ANALYZE выполняет изменяющую команду в служебной транзакции и откатывает её автоматически

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

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

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

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