🗄️ 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)

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

Вопрос 4 из 20

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

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

Вопрос 5 из 20

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

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

width Filter Planning Time 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 Индекс мало сокращает чтение, почти вся таблица всё равно нужна Seq Scan выбран потому, что планировщик не учитывает условия WHERE по boolean Индекс станет выгодным после добавления ORDER BY active без изменения фильтра

Вопрос 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 часто уместен?

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

Вопрос 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

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

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

Вопрос 18 из 20

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

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

Вопрос 19 из 20

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

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

Вопрос 20 из 20

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

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

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

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

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

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