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

Давайте воспользуемся той же схемой и оператором UPDATE, что и в прошлой статье. Чтобы получить план для каждого индекса мы можем обмануть оптимизатор, заставив его поверить в то, что таблица больше, чем она есть на самом деле. Для этого выполним несколько операций UPDATE STATISTICS с параметрами ROWCOUNT и PAGECOUNT. (Конечно, мы могли бы увеличить таблицу, вставив больше строк, но способ с UPDATE STATISTICS работает быстрее.)

CREATE TABLE T (PK INT, A INT, B INT, C INT, D INT, E INT)
CREATE UNIQUE CLUSTERED INDEX TPK ON T(PK)
CREATE INDEX TB ON T(B)
CREATE INDEX TCD ON T(C,D)
CREATE INDEX TE ON T(E)

INSERT T VALUES(0, 10, 20, 30, 40, 50)

UPDATE STATISTICS T WITH ROWCOUNT = 100000, PAGECOUNT = 10000
UPDATE STATISTICS T (TB) WITH ROWCOUNT = 100000, PAGECOUNT = 1000
UPDATE STATISTICS T (TCD) WITH ROWCOUNT = 100000, PAGECOUNT = 1000
UPDATE STATISTICS T (TE) WITH ROWCOUNT = 100000, PAGECOUNT = 1000

SET STATISTICS PROFILE ON
UPDATE T SET B = 29, C = 39, D = 49

Запустив оператор UPDATE с инструкцией SET STATISTICS PROFILE ON, мы можем увидеть точное количество строк, обработанных каждым оператором изменения индекса:

Rows   Executes
2      1        |--Sequence
2      1             |--Index Update(OBJECT:([T].[TB]), SET:([PK1036] = [T].[PK],[B1037] = [T].[B]) WITH ORDERED PREFETCH)
2      1             |    |--Sort(ORDER BY:([T].[B] ASC, [T].[PK] ASC, [Act1035] ASC))
2      1             |         |--Filter(WHERE:(NOT [Expr1031]))
2      1             |              |--Table Spool
2      1             |                   |--Split
1      1             |                        |--Clustered Index Update(OBJECT:([T].[TPK]), SET:([T].[B] = [Expr1025],[T].[C] = [Expr1026],[T].[D] = [Expr1027]))
1      1             |                             |--Compute Scalar(DEFINE:([Expr1031]=[Expr1031], [Expr1032]=[Expr1032]))
0      0             |                                  |--Compute Scalar(DEFINE:([Expr1031]=CASE WHEN [Expr1003] THEN (1) ELSE (0) END, [Expr1032]=CASE WHEN [Expr1004] AND [Expr1005] THEN (1) ELSE (0) END))
0      0             |                                       |--Compute Scalar(DEFINE:([Expr1025]=(29), [Expr1026]=(39), [Expr1027]=(49)))
0      0             |                                            |--Compute Scalar(DEFINE:([Expr1003]=CASE WHEN [T].[B] = (29) THEN (1) ELSE (0) END, [Expr1004]=CASE WHEN [T].[C] = (39) THEN (1) ELSE (0) END, [Expr1005]=CASE WHEN [T].[D] = (49) THEN (1) ELSE (0) END))
1      1             |                                                 |--Top(ROWCOUNT est 10000)
1      1             |                                                      |--Clustered Index Scan(OBJECT:([T].[TPK]), ORDERED FORWARD)
2      1             |--Index Update(OBJECT:([T].[TCD]), SET:([PK1038] = [T].[PK],[C1039] = [T].[C],[D1040] = [T].[D]) WITH ORDERED PREFETCH)
2      1                  |--Filter(WHERE:(NOT [Expr1032]))
2      1                       |--Sort(ORDER BY:([T].[C] ASC, [T].[D] ASC, [T].[PK] ASC, [Act1035] ASC))
2      1                            |--Table Spool

Давайте рассмотрим присутствующие в этом плане запроса операторы. Во-первых, обратите внимание, что часть между операторами просмотра кластерного индекса и операторами изменения кластерного индекса выглядит практически идентично построчному плану из предыдущей статьи. В частности, обратите внимание, что тут есть похожие операторы «Compute Scalar» которые определяют, какие индексы затронуло и они нуждаются в изменении. [Expr1031] определяет, нужно ли обновлять индекс TB, а [Expr1032] - нужно ли обновлять индекс TCD. Единственная реальная разница между этой частью плана и построчным планом в том, что в этом плане изменение кластерного индекса затрагивает только кластерный индекс и не изменяет ни одного некластерного индекса. Некластерные индексы тут изменяются отдельными операторами.

Далее идёт оператор SPLIT, который преобразует изменение строки в удаление и последующую вставку. Вот почему одна строка на входе SPLIT превращается в две строки на выходе. В этом плане операторы SPLIT и SORT предназначены исключительно для повышения производительности и их обсуждение не входит в рамки нашей темы.

Table Spool — это обычное подвыражение, которое все свои строки на входе передаёт далее на выход несколько раз. В нашем примере Table Spool выдаёт строки дважды: один раз для изменения индекса TB, а другой раз для изменения индекса TCD. Обратите внимание, что Table Spool ниже изменения индекса TCD является вторичным. У него нет входного потока строк, а вместо этого он выдаёт строки из буфера, расположенного между изменениями индекса TB и кластерного индекса.

Оператор Sequence склеивает две части плана вместе. Как следует из названия, каждое дочернее поддерево выполняется последовательно.

Наконец, в SQL Server 2005 впервые появился оператор Filter. Этот оператор для каждой строки проверяют результаты скалярных вычислений и определяет нужны ли изменения в каком-либо некластерном индексе. В нашем примере изменение одной строки влечёт за собой изменение в обоих индексах, и поэтому, после прохождения строки через фильтр, каждый оператор изменения индекса получает две строки (вспомните, что SPLIT преобразовал изменение строки в удаление и вставку).

Если мы выполним тоже самое обновление ещё раз, то увидим, что фильтры отбросят строки, поскольку данные не изменяются, и некластерные индексы менять не нужно. Обратите внимание, что оба оператора изменения индекса не изменяют ни одной строки:

Rows   Executes
0      1        |--Sequence
0      1             |--Index Update(OBJECT:([T].[TB]), SET:([PK1036] = [T].[PK],[B1037] = [T].[B]) WITH ORDERED PREFETCH)
0      1             |    |--Sort(ORDER BY:([T].[B] ASC, [T].[PK] ASC, [Act1035] ASC))
0      1             |         |--Filter(WHERE:(NOT [Expr1031]))
2      1             |              |--Table Spool
2      1             |                   |--Split
1      1             |                        |--Clustered Index Update(OBJECT:([T].[TPK]), SET:([T].[B] = [Expr1025],[T].[C] = [Expr1026],[T].[D] = [Expr1027]))
1      1             |                             |--Compute Scalar(DEFINE:([Expr1031]=[Expr1031], [Expr1032]=[Expr1032]))
0      0             |                                  |--Compute Scalar(DEFINE:([Expr1031]=CASE WHEN [Expr1003] THEN (1) ELSE (0) END, [Expr1032]=CASE WHEN [Expr1004] AND [Expr1005] THEN (1) ELSE (0) END))
0      0             |                                       |--Compute Scalar(DEFINE:([Expr1025]=(29), [Expr1026]=(39), [Expr1027]=(49)))
0      0             |                                            |--Compute Scalar(DEFINE:([Expr1003]=CASE WHEN [T].[B] = (29) THEN (1) ELSE (0) END, [Expr1004]=CASE WHEN [T].[C] = (39) THEN (1) ELSE (0) END, [Expr1005]=CASE WHEN [T].[D] = (49) THEN (1) ELSE (0) END))
1      1             |                                                 |--Top(ROWCOUNT est 10000)
1      1             |                                                      |--Clustered Index Scan(OBJECT:([T].[TPK]), ORDERED FORWARD)
0      1             |--Index Update(OBJECT:([T].[TCD]), SET:([PK1038] = [T].[PK],[C1039] = [T].[C],[D1040] = [T].[D]) WITH ORDERED PREFETCH)
0      1                  |--Filter(WHERE:(NOT [Expr1032]))
2      1                       |--Sort(ORDER BY:([T].[C] ASC, [T].[D] ASC, [T].[PK] ASC, [Act1035] ASC))
2      1                            |--Table Spool

Мы тут тоже могли бы использовать другие способы отслеживания работы операторов, которые были продемонстрированы в предыдущей статье (то есть запросы к sys.dm_db_index_operational_stats, анализ удерживаемых блокировок или отслеживание числа операций логических чтений страниц из памяти), чтобы убедиться, что некластерные индексы в самом деле не обновлялись. Автор предлагает вам попрактиковаться в этом самостоятельно.

Внутренняя оптимизация для индексов в «широком» плане запроса