Производительность T-SQL MERGE в типичном контексте публикации

Стоимость поддерева следует воспринимать с большой долей скептицизма (особенно, когда у вас есть огромные ошибки кардинальности). Выход SET STATISTICS IO ON; SET STATISTICS TIME ON; является лучшим индикатором фактической производительности.

Сортировка по нулевой строке не занимает 87% ресурсов. Эта задача в вашем плане связана с оценкой статистики. Затраты, указанные в фактическом плане, по-прежнему являются сметными затратами. Это не приводит их в соответствие с тем, что произошло на самом деле.

В плане есть точка, где фильтр уменьшает 1 911 721 строку до 0, но предполагаемое количество строк в будущем составляет 1 860 310 строк. После этого все затраты являются фиктивными, кульминацией которых является 87%-ная стоимость, оцениваемая в 3 348 560 строк.

Ошибку оценки количества элементов можно воспроизвести вне оператора Merge, взглянув на оценочный план для Full Outer Join с эквивалентными предикатами (дает ту же оценку 1 860 310 строк).

SELECT * 
FROM TargetTable T
FULL OUTER JOIN  @tSource S
    ON S.Key1 = T.Key1 and S.Key2 = T.Key2
WHERE 
CASE WHEN S.Key1 IS NOT NULL 
     /*Matched by Source*/
     THEN CASE WHEN T.Key1 IS NOT NULL  
               /*Matched by Target*/
               THEN CASE WHEN  [T].[Data1]<>S.[Data1] OR 
                               [T].[Data2]<>S.[Data2] OR 
                               [T].[Data3]<>S.[Data3]
                         THEN (1) 
                     END 
                /*Not Matched by Target*/     
                ELSE (4) 
           END 
       /*Not Matched by Source*/     
      ELSE CASE WHEN  [T].[Key1]=@id 
                THEN (3) 
            END 
END IS NOT NULL

Тем не менее, план до самого фильтра выглядит довольно неоптимальным. Он выполняет полное сканирование кластеризованного индекса, когда, возможно, вам нужен план с двумя поисками диапазона кластеризованного индекса. Один для извлечения одной строки, соответствующей первичному ключу, из соединения в источнике, а другой для извлечения диапазона T.Key1 = @id (хотя, может быть, это сделано для того, чтобы избежать необходимости сортировки в кластерном порядке ключей позже?)

Возможно, вы могли бы попробовать это переписать и посмотреть, работает ли он лучше или хуже.

;WITH FilteredTarget AS
(
SELECT T.*
FROM TargetTable  AS T WITH (FORCESEEK)
JOIN @tSource S
    ON (T.Key1 = S.Key1
    AND S.Key2 = T.Key2)
    OR T.Key1 = @id
)
MERGE FilteredTarget AS T
USING @tSource S
ON (T.Key1 = S.Key1
   AND S.Key2 = T.Key2)


-- Only update if the Data columns do not match
WHEN MATCHED AND S.Key1 = T.Key1 AND S.Key2 = T.Key2 AND 
                                         (T.Data1 <> S.Data1 OR
                                          T.Data2 <> S.Data2 OR 
                                          T.Data3 <> S.Data3) THEN
  UPDATE SET T.Data1 = S.Data1,
             T.Data2 = S.Data2,
             T.Data3 = S.Data3

-- Note from original poster: This extra "safety clause" turned out not to
-- affect the behavior or the execution plan, so I removed it and it works
-- just as well without, but if you find yourself in a similar situation
-- you might want to give it a try.
-- WHEN MATCHED AND (S.Key1 <> T.Key1 OR S.Key2 <> T.Key2) AND T.Key1 = @id THEN
--   DELETE

-- Insert when missing in the target
WHEN NOT MATCHED BY TARGET THEN
    INSERT (Key1, Key2, Data1, Data2, Data3)
    VALUES (Key1, Key2, Data1, Data2, Data3)

WHEN NOT MATCHED BY SOURCE AND T.Key1 = @id THEN
    DELETE;