Краткий ответ

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

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

Исторический контекст

Реляционная алгебра была создана как формальный аппарат для работы с отношениями. Её операции позволяют описывать результат запроса независимо от конкретного способа физического выполнения.

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

Постановка проблемы

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

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

Подробное решение

В реляционной алгебре фильтрация называется селекцией. Последовательное применение селекций можно представить как применение одного фильтра с логическим оператором AND:

SELECT *
FROM payments
WHERE status = 'active' AND amount > 0;

SELECT *
FROM payments
WHERE amount > 0 AND status = 'active';

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

Это свойство сохраняется и при трёхзначной логике SQL. Значения предикатов могут быть TRUE, FALSE или UNKNOWN, но операция AND коммутативна: результат p AND q совпадает с результатом q AND p. В WHERE проходят только строки с результатом TRUE; FALSE и UNKNOWN отбрасываются.

Логическая эквивалентность не означает одинаковый план выполнения. Оптимизатор может применить более селективный фильтр раньше, использовать индекс, протолкнуть условие ближе к источнику данных или объединить несколько условий.

Порядок условий также не является механизмом защиты от ошибок. Выражение вроде проверки ненулевого делителя в одном предикате не гарантирует, что другой предикат с делением будет вычислен только после неё. Безопасность нужно обеспечивать самим выражением, например использовать безопасное преобразование или NULLIF.

Ситуация из практики

В отчёте нужно выбрать платежи с ненулевой суммой и вычислить отношение комиссии к сумме. Разработчик записал проверку ненулевой суммы рядом с выражением деления и рассчитывает, что СУБД сначала исключит нулевые строки.

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

Надёжное решение — сделать само деление безопасным, например заменить делитель на NULLIF(amount, 0). Тогда для нулевой суммы получится NULL, а условие фильтрации не даст такой строке пройти; выбранный подход устраняет зависимость от плана выполнения и предотвращает ошибку.

Что кандидаты часто упускают

1. Меняется ли коммутативность фильтров из-за NULL?

Нет, сама коммутативность не меняется. Если один или оба предиката дают UNKNOWN, результат их AND одинаков при любом порядке. Ошибка обычно возникает не из-за перестановки, а из-за неверного ожидания, что UNKNOWN трактуется как TRUE или как обычное FALSE во всех контекстах.

В WHERE результат UNKNOWN исключает строку, поэтому фильтр с NULL может убрать строку, даже если условие не является явно ложным.

2. Гарантирует ли первое условие в WHERE, что второе вычислится только для прошедших строк?

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

Поэтому потенциально опасное выражение нужно писать безопасно: проверять делитель внутри самого выражения, явно обрабатывать преобразование типов или предварительно нормализовать данные.

3. Если результат одинаков, почему порядок условий иногда влияет на скорость?

Порядок текста обычно не обязан влиять на итоговый план: оптимизатор может самостоятельно переставить условия. Но стоимость может измениться из-за статистики, доступных индексов, сложности выражений, пользовательских функций и качества оптимизации конкретной СУБД.

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