В практическом запросе фильтр исключает строки, но выражение в SELECT содержит потенциально ошибочное вычисление. Гарантирует ли SQL, что это выражение не будет вычислено для отброшенных строк?
Нет, такой гарантии нет. Логически WHERE обрабатывается раньше SELECT, но физический план может вычислять выражения в другом порядке, проталкивать фильтры или вычислять константные части заранее. Потенциально ошибочные вычисления нужно явно делать безопасными, например через CASE или NULLIF.
SQL основан на декларативной модели: запрос описывает требуемый результат, а не последовательность машинных операций. Это позволяет оптимизатору выбирать более эффективный план вместо буквального выполнения текста сверху вниз.
Логический порядок обработки нужен для понимания смысла запроса, но он не является инструкцией для физического исполнителя. Поэтому порядок, удобный для объяснения запроса, нельзя автоматически считать порядком вычисления каждого выражения.
Предположение, что WHERE обязательно защитит выражение SELECT от ошибки, может привести к сбоям при делении на ноль, преобразовании некорректных данных или вызове функций с ограниченной областью допустимых значений.
Даже если сегодня конкретная СУБД не вычисляет выражение для исключённых строк, изменение статистики, индекса, версии или плана может изменить физический порядок операций. Логика, зависящая от этого порядка, становится ненадёжной.
Логически запрос можно представить так: источник строк формируется через FROM, затем применяется WHERE, затем вычисляется список SELECT. Однако оптимизатор вправе преобразовывать план, если считает преобразование эквивалентным по результату.
Поэтому фильтр не следует использовать как единственную защиту от недопустимого выражения. Защиту нужно поместить непосредственно в выражение:
NULLIF(quantity, 0) превращает ноль в NULL, а деление на NULL даёт NULL вместо ошибки. Для более сложных условий подходит CASE, но и его ветви не следует считать универсальным механизмом управления физическим порядком вычислений: оптимизатор может заранее вычислить константные подвыражения или выполнить другие допустимые преобразования.
Практическое правило: логический порядок объясняет результат запроса, но не гарантирует порядок вычисления выражений. Для предотвращения ошибки используйте выражения, безопасные при любых входных данных, а не рассчитывайте на соседний фильтр.
В отчёте рассчитывали цену единицы товара и отдельно отбирали только строки с ненулевым количеством. В исходных данных иногда встречалось количество NULL, а оптимизация запроса менялась после создания индекса. В результате подход, основанный только на фильтре, был хрупким.
Рассматривались два варианта. Фильтрация строк перед расчётом проще для чтения, но не даёт надёжной защиты от вычисления выражения. Оборачивание делителя в NULLIF немного усложняет выражение, зато делает вычисление безопасным независимо от выбранного плана.
Выбрали второй вариант и отдельно обработали получившийся NULL в отчёте. Запрос перестал зависеть от плана выполнения, а отсутствие количества стало явно отличаться от ошибочного деления.
Нет. Логический порядок — модель, позволяющая определить семантику результата: какие строки доступны фильтру, группировке и списку выбора. Физический план может использовать индексы, менять порядок соединений, проталкивать предикаты и удалять лишние вычисления.
Гарантируется результат, соответствующий семантике SQL, но не последовательность внутренних операций. На порядок можно опираться только там, где он выражен конструкцией языка, а не предположением о плане.
Для обычного построчного условного вычисления CASE предназначен именно для выбора подходящей ветви, поэтому это предпочтительный способ выразить условную защиту. Но оптимизатор может заранее вычислить независимое константное подвыражение или выполнить иное допустимое преобразование.
Следовательно, лучше избегать опасных константных выражений и делать сами операнды безопасными. Для деления обычно надёжнее использовать NULLIF, а для преобразований — предварительно проверять формат или применять безопасный механизм, предоставляемый конкретной СУБД.
Само вынесение не обязательно создаёт материализованный промежуточный результат и не гарантирует физический порядок. Оптимизатор может встроить подзапрос или CTE в общий план и снова изменить порядок вычислений.
Если требуется именно промежуточное сохранение результата, нужно использовать механизм материализации, когда он поддерживается и действительно необходим. Но обычно правильнее не полагаться на материализацию, а выразить вычисление безошибочно — например, через NULLIF или корректное условное выражение.