Будет ли запрос WHERE проверять более простые сравнения (т.е. битовые) перед выполнением более трудных сравнений (например, varchar)?

12

Если я напишу запрос, который включает составное WHEREпредложение, например:

SELECT *
FROM MyTable
WHERE BitField = 1
    AND VarcharField = 'asdf'

и включение этого bitсравнения просто исключает те же поля, varcharкоторые исключает сравнение, сделает ли bitсравнение этих полей улучшение производительности?

sql-server optimization

— andrewb
источник

22

Важно признать, что SQL является декларативным языком. SELECTЗапроса Вы писали Указываются логические результаты , которые должны быть возвращены. Именно ядро базы данных, в частности оптимизатор запросов, может определить эффективную физическую стратегию для возврата этих результатов.

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

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

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

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

Чтобы ответить на вопрос напрямую (в конечном итоге!), Добавление дополнительного избыточного условия может улучшить производительность, но только если оно позволяет использовать более эффективный метод доступа - например, если включен только индекс (BitField, VarcharField). Если бы уже был индекс на (VarcharField), это добавило бы только накладные расходы.

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

Смежные вопросы:

Логические операторы ИЛИ И в условии и порядке условий в WHERE
SQL Server 2008 и константных выражениях
Битовые операторы, влияющие на производительность Странное поведение операторов
SQL

— Пол Уайт 9
источник

5

Двоичные разделы (например, битовый столбец) звучат как хорошие кандидаты в отфильтрованные индексы.

CREATE NONCLUSTERED INDEX MyTableWithBitFieldTrue
ON MyTable (VarcharField)
INCLUDE Id, <other columns you're selecting>
WHERE BitField = 1 ;
GO

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

— Greg
источник