Прошу прощения за реанимацию давно угаснувшей дискуссии, я просматривал архив и это сообщение меня заинтересовало. Dmitry действительно обнаружил очень любопытный факт, но сделал из него абсолютно неверные выводы. Ближе всех к истине подошел Nick, но в конце почему-то сдался. Во-первых, отбросим несущественное. Индексы и SARGи здесь ни при чем. Вопрос состоит в следующем: выполняет ли SQL Server запросы с where = <false>. Надеюсь, понятно о чем речь, а то мне тут один заявил, типа, ясен пень, что нет, он же пишет: 0 rows affected. Я категорически не согласен с оценками типа "Позор джунглям", "Глюкало" и утверждаю, что процессор запросов оценивает константу фильтра априори без последующего сравнения row by row и траты на это циклов процессора и прочих системных ресурсов. Проведем следующий эксперимент: включим в QA Show Server Trace (Ctrl-Shift-T) и Show Execution Plan (Ctrl-K) для вывода времени выполнения запроса и показа реального плана выполнения. Да, Dmitry, estimated execution plan может иногда не совпадать с фактическим, это не бред, а просто жизнь так устроена, что не всегда на стадии компиляции его можно построить однозначно. Например, если запрос с параметрами или SQL Server сам решает использовать автопараметризацию, то, очевидно, что это значения параметров выяснятся только во время run-time. Возможны и другие причины. Возьмем запрос select * from orders o1, orders o2, orders o3, orders o4, orders o5 where sin(0)=sin(1) и посмотрим estimated plan. Мать моя, оказывается, он собирается вернуть 3.9Е+14 записей. Полный бред, суксь, маздай, кто так строит, наберут, блин, по объявлению и пр. А теперь не побоимся его выполнить и посмотрим реальный план (закладка Execution Plan в панели результатов). Вы видите, что фактический row count везде = 0. Хорошо, но, может быть, SQL Server все-таки выполнял этот запрос? Нет. Смотрите, Number of executes у самого правого верхнего оператора Index Scan = 0. Для иллюстрации сравним, напр., с select * from orders o1, orders o2, orders o3, orders o4, orders o5 where o1.freight=sin(1). Несмотря на то, что row count здесь тоже = 0, Number of executes = 1, так что данный запрос в отличие от предыдущего действительно выполняется. Почистим процедурный кэш, свободные буфера и сравним время выполнения (закладка trace). Оно, конечно, зависит от вашей тачки, но я уверен, что для второго запроса Duration, CPU, Reads у вас будут превышать аналогичные показатели для первого.