VicN,

Добрый день.

В самом запросе можно «провернуть», как уже выше сказали, добавив дополнительно условие «and @var is not null». Это только для помощи оптимизатору, т.к. логически, в данном случае, это одно и то же. Но дополнительный предикат, дает серверу возможность использовать Startup Filter. Это такой вид фильтра, в котором проверяется некоторое выражение (Startup Expression Predicate) и если оно не выполняется, то вся нижележащая/дочерняя ветка плпнп не будет выполняться.

Добавьте в запросе в условие where «and @var is not null», и посмотрите в свойствах появившегося оператора фильтра Startup Expression Predicate: [@var] IS NOT NULL. Далее сравните в вашем плане и в получившемся свойство Number of Executions оператора Clustered Index Seek, в первом оно 1, т.е. оператор вызывался, во втором 0, т.е. не вызывался.

Хотя на уровне Storage Engine и то, и то не осуществляет доступ к строкам, включите «statistics io», и посмотрите число логических чтений, либо на более поздних версиях, можно посмотреть свойство самого оператора «Actual IO Statistics» и «Number of Rows Read» (которого не будет ни в том, ни в другом случае), можно также посмотреть sys.dm_db_index_operational_stats, чтобы убедиться, что никакого физического доступа нет.

В этом смысле сервер не дурак, так что не переживайте, что: «смущает не только, что сервер делает поиск» - он не делает в данном случае (если только вы не отключите ANSI_NULLS и не сделаете колонку nullable, исключив из РК, если так, то разница в физическом доступе будет, и вы это увидите по всем признакам, перечисленным выше).

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

Далее, по вопросу: «какое то обновление кластерного индекса. Ведь я индекс совсем не трогаю. Зачем все это?»

Операция обновления в SQL Server всегда состоит из двух частей - Read Cursor (не тот, не пользовательский курсор, а внутри сиквела, цикл по строкам), и Write Cursor. Один набирает строки для модификации (например, Clustered Index Seek), другой модифицирует (например, Clustered Index Update). В некоторых простых случаях, сервер, умеет это сворачивать в один оператор:


Планы имеют, кроме корневого элемента (INSERT/UPDATE/DELETE), всего по одному оператору плана, который совмещает Write + Read курсоры.

Это работает для самых простых случаев.

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


Тогда планы такие, какие должны быть без дополнительной оптимизации.


Вывод из этого такой:
более-менее сложные запросы обновления должны так или иначе содержать в себе часть Read (которая не обязательно получает доступ к строкам, это может быть просто Constant Scan) и часть Write – такова особенность внутренней реализации сиквела.
Так что ваш план содержит Update не потому, что он реально что-то обновляет если NULL, а by design.

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


Во втором:


Несмотря на то, что оба запроса не затрагивают никаких строк по условию 1=0, все равно второй будет заблокирован и будет ждать, пока вы не закончите транзакцию первого. А т.к. итераторы выполнения (не только update, но и все остальные) должны корректно работать с блокировками, логика запроса не единственное, что обуславливает их физический дизайн.

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