在视图查询中应用 WHERE 子句的时间点是什么？

当使用视图执行查询时（也使用内联表值函数），优化器会将视图定义替换到查询中并尝试优化生成的复合查询。

В первом случае запрос скорее всего выполнится как

SELECT
    tt.PKID AS ИД,
    tt.Name AS Наименование,
    tt.priceIn AS Вход,
    tt.Price AS Цена
FROM Item AS tt
WHERE tt.iditem IS NOT NULL AND tt.PKID = 12345;

А во втором, по-видимому, как

WITH CTE([ИД],
    [Наименование],
    [Вход],
    [Цена],
    rnumber,
    rcount)
AS (SELECT tt.PKID AS ИД,
        tt.Name AS Наименование,
        tt.priceIn AS Вход,
        tt.Price AS Цена,
        ROW_NUMBER() OVER(PARTITION BY tt.pkid ORDER BY tt.sn) AS rnumber,
        COUNT(tt.sn) OVER(PARTITION BY tt.pkid) AS rcount
    FROM Item AS tt
    WHERE tt.iditem IS NOT NULL AND tt.PKID = 12345)
SELECT *
FROM CTE AS c
WHERE c.rcount = 1;

т.к. во внутреннем запросе нумерация и подсчёт количества происходят в группах, разбитых по tt.PKID, а предикат tt.PKID = 12345, так же как и c.rcount = 1, делает фильтрацию группы.

При построении плана запроса оптимизатор старается применять предикаты настолько рано, насколько это возможно (т.н. predicate pushdown или filter pushdown), т.к., во-первых, выгодно на ранних этапах плана отсечь ненужные данные (меньше работы на следующих этапах), и, во-вторых, раннее применение предиката положительно сказывается на возможности использования индексов.

Рассмотрим пример. Пусть есть таблица

DECLARE @item TABLE(A int, B int);
INSERT INTO @item VALUES (1, 2), (2, NULL);

Выполним запрос с подзапросом

SELECT *
FROM (
    SELECT *
    FROM @item
    WHERE B IS NOT NULL
    ) I
WHERE A = 1;

и посмотрим план выполнения (графический и текстовый)

|--Table Scan(OBJECT:(@item), WHERE:([A]=(1) AND [B] IS NOT NULL))

Как видим, оптимизатор объединил оба условия и поместил их в узел Table Scan (чтение данных таблицы).

Если бы запрос исполнялся именно так как он записан, то мы бы увидели

|--Filter(WHERE:([A]=(1))
  |--Table Scan(OBJECT:(@item), WHERE:([B] IS NOT NULL))

т.е. чтение таблицы с условием [B] IS NOT NULL как первый этап плана, и фильтрацию набора строк с условием [A]=(1) как второй его этап. В данном случае вряд ли это заметно понизило бы производительность. Если бы, однако, на столбце [A] у нас был индекс, то такой план не позволил бы его использовать оптимально (или даже вовсе).

Однако для применения predicate pushdown у оптимизатора должно быть достаточно оснований. Препятствовать этому виду оптимизации может использование в предикатах недетерминированных выражений (в т.ч. с участием пользовательских скалярных функций). Также ни один вид оптимизации не должен нарушать семантику запроса (корректность результата превыше скорости).

Смоделируем второй случай. Пусть есть таблица с данными

DECLARE @item TABLE (A int, B int, C char(1));
INSERT INTO @item VALUES
    (1, NULL, NULL), (1, 1, 'X'),
    (2, 1, NULL),
    (3, NULL, NULL), (3, 1, NULL), (3, 1, 'Y'),
    (4, NULL, NULL), (4, 1, 'Z');

Мы делаем запрос

WITH R1 AS (
    SELECT
        A, B, C,
        Num = ROW_NUMBER() OVER(PARTITION BY A ORDER BY C),
        Cnt = COUNT(C) OVER(PARTITION BY A)
    FROM @item
    WHERE B IS NOT NULL
),
R2 AS (
    SELECT *
    FROM R1
    WHERE Cnt = 1
)
SELECT *
FROM R2
WHERE A = 1;

семантика которого такова:

1. Выбираем данные, делаем нумерацию и подсчёт в группах по A
2. Берём только группы с COUNT(C) = 1
3. Оставляем только записи с A = 1

План выполнения запроса

|--Filter(WHERE:([Expr1004]=(1)))
  |--Nested Loops(Inner Join)
    |--Table Spool
      |  |--Segment
      |    |--Sequence Project(DEFINE:([Expr1003]=row_number))
      |      |--Segment
      |        |--Sort(ORDER BY:([C] ASC))
      |          |--Table Scan(OBJECT:(@item), WHERE:([A]=(1) AND [B] IS NOT NULL))
      |--Nested Loops(Inner Join, WHERE:((1)))
        |--Compute Scalar(DEFINE:([Expr1004]=CONVERT_IMPLICIT(int,[Expr1007],0)))
        |  |--Stream Aggregate(DEFINE:([Expr1007]=COUNT([C])))
        |    |--Table Spool
        |--Table Spool

показывает, однако, что условие A = 1, заданное на последнем этапе, оптимизатор перенёс на первый этап, объединив его с [B] IS NOT NULL в узле Table Scan.

Если изменить запрос, убрав PARTITION BY, например

WITH R1 AS (
    SELECT
        A, B, C,
        Num = ROW_NUMBER() OVER(ORDER BY C),
        Cnt = COUNT(C) OVER()
    FROM @item
    WHERE B IS NOT NULL
),
R2 AS (
    SELECT *
    FROM R1
    WHERE Cnt = 1
)
SELECT *
FROM R2
WHERE A = 1;

то это меняет семантику запроса так, что оптимизатор уже не может применить условие [A] = 1 при чтении данных из таблицы, и в плане запроса

|--Filter(WHERE:([A]=(1) AND [Expr1004]=(1)))
  |--Nested Loops(Inner Join)
    |--Table Spool
    |  |--Segment
    |    |--Sequence Project(DEFINE:([Expr1003]=row_number))
    |      |--Segment
    |        |--Sort(ORDER BY:([C] ASC))
    |          |--Table Scan(OBJECT:(@item), WHERE:([B] IS NOT NULL))
    |--Nested Loops(Inner Join, WHERE:((1)))
      |--Compute Scalar(DEFINE:([Expr1004]=CONVERT_IMPLICIT(int,[Expr1007],0)))
      |  |--Stream Aggregate(DEFINE:([Expr1007]=COUNT([C])))
      |    |--Table Spool
      |--Table Spool

мы видим в свойствах Table Scan лишь условие [B] IS NOT NULL, а условие [A]=(1) применяется в Filter на самом последнем этапе.