Как стать автором
Обновить

Каверзные вопросы на интервью аналитика: В каком порядке обрабатываются SQL-запросы?

Время на прочтение5 мин
Количество просмотров28K
Всего голосов 28: ↑16 и ↓12+7
Комментарии33

Комментарии 33

Начнем сразу с порядка выполнения запроса

Каковой порядок состоит из компиляции - анализа всех выражений, проверки совместимости типов, видимости объектов, разрешения имен и алиасов, разворачивания представлений и т.д., оптимизации - построения нескольких планов (алгоритмов), оценки их сложности/стоимости, выбора окончательного плана выполнения, и непосредственно выполнения.

Насколько бесполезным станут эти знания в... этом году, думаю. Вас это не коробит? Серьезно.

Почему они станут бесполезными? Типа движки БД уже написаны и застыли в янтаре? Больше их развивать не надо?

Знание о том, что земля вращается вокруг солнца и совсем не плоская вам в этом году тоже не пригодится. Но вас же от этого не коробит?

Мистер Холмс, опять вы за старое...

Знание о том, что земля вращается вокруг солнца

Это не знание, а популярное заблуждение. :)

Join’ы и with забыли ;)

Причём JOIN бывают и LATERAL (включая table function).

А CTE вообще могут быть как cached/materialized, так и inline, и разные типы приводят к получению разных результатов выполнения вроде одного и того же запроса на одних и тех же данных.

Скажите спасибо, что забыли. А то бы еще не дай бог начали объяснять чем LEFT JOIN отличается от RIGHT :)

Я вот не пойму, у вас копеек на фриланс-дизайнера не хватает, чтобы заказать ему красивую картинку с блок-схемой, или так хочется выпендриться "смотрите, мы тоже умеем запросы к LLM писать"? Что за "secrect", нечитаемые иероглифы и абсолютно бессмысленные линии на КДПВ?

Имею версию.

Если нанимать человека, то ему надо ставить задание, возвращать на доработку и принимать результат. Ну и потом отчитываться перед своим начальством за то, что принял у дизайнера какую-то хрень.

А тут просто говоришь "да это же чатжпт - он сам что-то рисует и хрен на это повлияешь" и у тебя проблем не возникает.

Не думаю что данная статья столь важна и серьезна для наема иллюстраторов и дизайнеров, верстальщиков и редакторов.

Начнем сразу с порядка выполнения запроса

Пропущен пункт с точкой вычисления Window Functions - масса проблем с ними вызвана именно непониманием того, когда они выполняются.

А если оконные функции совмещены с агрегатными на одном уровне вложенности, то без документации вообще мало кто вспомнит порядок их вычисления.

Не хватает дополнения "считается, что запрос отрабатывает в такой-то последовательности.."

Кажется, что современные интерпретаторы кода очень умные и иногда могут нарушать указанный порядок.

В частности, в гринплам селект с фильтром к миллиардной табличке с лимитом и без лимита будет отрабатывать радикально разное время - те гринплам похоже как-то засовывает лимит не в самый конец..

засовывает лимит не в самый конец..

Конкретно этот случай возможно не очевидный, но иногда предикаты можно протолкнуть внутрь скажем подзапросов, и такая оптимизация широко используется.

По-хорошему, вам следовало бы получить и показать нам тут план запроса в обоих случаях. Думаю многое можно было бы понять.

Я просто запомнил "Фьоугхсоль" на ктулхском😃

FJOWGHSOL

from, join on, where, group by, having, select, order by, limit(или top)

Каверзные вопросы на интервью аналитика: В каком порядке обрабатываются SQL-запросы?

Только мне одному кажется, что в тексте ответ на другой вопрос?

Причём, тот вопрос который в тексте (в каком порядке выполняются элементы одного запроса), он вообще не особо интересен, потому что ни на что не влияет - порядок определяется интерпретатором.

Да. Когда я читаю "В каком порядке обрабатываются SQL-запросы?" - и это понимаю как "есть два запроса, в каком порядке они будут выполнены". А текст совсем про другое. Потому что в названии запросы во множественном, а текст про запрос в единственном.

Рассмотренный же в тексте вопрос не то чтобы не интересен, а скорее на практике обычно ставится в другой постановке: берется план, из которого видно порядок выполнения, если запрос работает медленно, пытаемся оптимизировать. Т.е. скажем, вопрос "как выполняется join" - он на самом деле интересен, особенно если вы знаете, как повлиять на выбор hash join или loop, например, и понимаете когда и какой лучше. А что до фильтров, то интересно обычно то, можно ли сделать им push в подзапрос, к примеру, то есть выполнить их как можно раньше, уменьшив число обрабатываемых на следующих этапах строк.

Порядок выполнения инструкций sql запроса - это то, про что текст. Про порядок выполнения sql запросов в тексте ничего нет.

Вы серьезно задаете такие бредовые вопросы системному аналитику? Серьезно?!

Вот именно про "порядок исполнения". Нет слов...

И ждете ответа как от разработчика ядра SQL-сервера или как просто специалиста по написанию и отладки SQL-ей?

Ну надо же что-то спросить с умным видом.

не системному аналитику, а

джунов и выпускников ИТ-курсов по специальности «системный аналитик».

Кстати всегда было интересно чему учат на курсах по специальности «системный аналитик». Теперь понятно.

А кому какая разница, в каком порядке это происходит? Вы что, системы управления базами данных разрабатываете? Конкретный порядок зависит от типа субд и ее версии, может, еще наличия установленных патчей. В общем, вопрос из разряда, чтобывот! Как некоторые спрашивают у соискателя на должность дба знание стека tcpip, потому что не знают, что надо спросить по существу.

И да, как многие уже отметили, заголовок статьи рисует в голове ситуацию с несколькими запросами, а тело статьи рассказывает про какой-то один запрос.

Запрос выполняется в порядке, установленном планом выполнения запроса, который имеет весьма опосредованное отношение к исходному тексту на языке SQL. Отдельные части оператора SQL сами по себе не являются исполняемыми. Ваш КО.

Если бы выполнение начиналось с FROM, как вы пишете в статье, то для начала читались бы все перечисленные во FROM таблицы (в том числе, например, и такие, которые не используются в остальной части запроса).

Дополню: SQL - декларативный язык (отвечает на вопрос "что получить"), а порядок получения данных императивен.

Например, применительно к PostgreSQL: сначала парсер создаёт дерево запроса (query tree), которое затем может быть трансформировано, затем приходит оптимизатор (optimizer), затем планировщик (planner).

Важно, что план формируется не в терминах SQL, а в терминах узлов дерева плана. Затем, наконец, этот план выполняет executor.

The executor takes the plan created by the planner/optimizer and recursively processes it to extract the required set of rows (https://www.postgresql.org/docs/current/executor.html).

Причём в зависимости от данных, фактически лежащих в БД, целык куски этого плана могут быть пропущены.

However, there are cases where the executor can determine that certain nodes need not be executed because they cannot produce any rows, based on parameter values that were not available at planning time (https://www.postgresql.org/docs/current/using-explain.html)

Кандидату на позицию системного аналитика я задаю вопросы про системный анализ. Первый и самый каверзный из них - какими он видит свои задачи на этой позиции.

Далее нужно понять базовый профессиональный уровень:

  • умеет ли находить нужные для его работы данные в БД и логах, или каждый раз будет просить кого-то, чтобы поискал;

  • с помощью каких знаний занимается проектированием интерфейсов и интеграций;

  • как будет разбираться в атрибутном составе данных.

Далее - кругозор, в частности:

  • что знает про СУБД, используемые конкретно у нас, и на каком уровне;

  • про разные протоколы синхронных и асинхронных интеграций.

Далее - про комфортный лично для него уровень взаимодействия с товарищами по команде:

  • какие вводные обычно просит от этапа бизнес-анализа (только бизнес-требования или пользовательские сценарии);

  • по каким вопросам предпочитает взаимодействовать с архитектором, в чём видит разницу компетенций и обязанностей;

  • консультирует ли разработку, консультируется ли у разработки. Если да, по каким вопросам.

Исходя из этого - составляю мнение о том, есть ли шансы на взаимную симпатию.

Ответ на вопрос из статьи мне ничем не поможет при отборе: аналитика, разработчика, DBA, SRE или кого бы то ни было ещё.

Мда.. Я бы поостерегся взять на работу автора статьи после её прочтения по следующим причинам:

  1. Автор уверен, что его вопрос "В каком порядке обрабатываются SQL-запросы" может быть понят единственным образом: "в каком порядке БД (какая?) обычно обрабатывает данные для формирования ответа на одиночный SQL запрос к одной таблице без джойнов, функций и подзапросов". При этом выше в комментариях написали уже минимум два других способа интерпретировать вопрос и это не предел.

  2. В статье полностью проигнорирован тот факт, что SQL - декларативный язык. По определению, текст запроса с select содержит требования ЧТО достать из БД, а вот КАК это делать - это работа движка БД (по крайней мере, пока в тексте запроса нет хинтов).

    Всё, чему посвящена статья - разбор очень примитивного частного случая, причем наверняка даже для него будет куча исключений у разных движков БД (совсем не уверен что какая-нибудь поколоночная inmemory БД будет обрабатывать запрос по описанному автором плану)

Я согласен, что этот вопрос должен хорошо быть разобран для джунов, стажеров, и задаваться в том числе мидлам. Но в чем каверзность? Этот вопрос встречается практически на всех курсах, и всегда стоит в топе вопросов на собеседование.

Изучать базу данных, с абсолютным непониманием (и ключевое - нежеланием, т.к. для него вопрос каверзный) как работают запросы - по мне такой человек в принципе не должен быть нанят

Я системный аналитик. Система, с которой я работаю, использует СУБД MS SQL. Но ко мне никогда не приходили с подобным вопросом о порядке обработки. Какая практическая ценность у этой информации? Написать запрос по другому, поменяв места, не получится, будет ошибка.

Надо же до чего то докопаться, тоже не понятен смысл вопроса, если все операции выполняются в ядре БД, и могут выполняться по разному, сотни SQL запросов написал, никогда не вставала необходимость понимания порядка их выполнения, а на собесе тебя из за этого непонимания могут отсеять

В воркбенче подсказки выбора колонок выходит после прописи таблицы. Я не айтишник, вторую неделю изучаю воркбенч, может там и настроить можно иначе, но теперь запросы пишу с form, а затем select, неудобно.

Знаете... у меня опыт в написании запросов немаленький, использовать любой intellisense мне даже в голову не придёт, если оно есть в ide, отключу сразу. НО!

Всегда начинаю написание запроса, кроме уж совсем тривиальных, с того, что пишу SELECT, 2 раза жму Enter, пишу FROM, и только потом пишу всё остальное - и кляузы, и конструкции, и имена...

Зарегистрируйтесь на Хабре, чтобы оставить комментарий