В предыдущей статье было показано как 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, анализ удерживаемых блокировок или отслеживание числа операций логических чтений страниц из памяти), чтобы убедиться, что некластерные индексы в самом деле не обновлялись. Автор предлагает вам попрактиковаться в этом самостоятельно.
ссылка на оригинал статьи https://habr.com/ru/post/713310/
Добавить комментарий