Подсчет высокого плана в мониторе активности SQL Server 2008
-
01-10-2019 - |
Вопрос
у меня есть MERGE
Запрос, чтобы создать операцию UPSERT в моей базе данных с данными, введенными через мое приложение. Когда я пойду называть это, чтобы сохранить свои данные о больших транзакциях (> 5000), это требует очень Долгое время (~ 20-40 секунд).
Вот мой MERGE
утверждение
MERGE TestTable AS target USING (SELECT @Guid) AS source (target.Guid = source.Guid)
WHEN MATCHED THEN
UPDATE TestTable SET Column1 = @Column1, Column2 = @Column2 WHERE Guid = @Guid
WHEN NOT MATCHED THEN
INSERT INTO TestTable (Column1, Column2) VALUES (@Column1, @Column2)
OUTPUT $action
Я называю это одним объектом за раз в моем коде .NET.
Я заметил, что в мониторе активности видимости SQL Express 2008 Monitor Monitor, что подсчет плана доходит до около 900 из-за всех различных параметров перестановок, с которыми называется запрос. Я также замечаю, что если я повторяю то же самое вскоре после с несколькими разными параметрами, он экономит много быстрее (~ 2 секунды).
Это потенциальная проблема производительности и причина длительного времени сроки времени?
Я использую SQL Express 2008 R2.
Редактировать: вот план:
|--Compute Scalar(DEFINE:([Expr1044]=CASE WHEN [Action1004]=(1) THEN N'UPDATE' ELSE CASE WHEN [Action1004]=(4) THEN N'INSERT' ELSE N'DELETE' END END))
|--Assert(WHERE:(CASE WHEN NOT [Pass1238] AND [Expr1237] IS NULL THEN (0) ELSE NULL END))
|--Nested Loops(Left Semi Join, PASSTHRU:([Action1004]=(3) OR [C:\DATABASE.MDF].[dbo].[DoorTable].[CarTable_Guid] as [target].[CarTable_Guid] IS NULL), OUTER REFERENCES:([C:\DATABASE.MDF].[dbo].[DoorTable].[CarTable_Guid]), DEFINE:([Expr1237] = [PROBE VALUE]))
|--Clustered Index Merge(OBJECT:([C:\DATABASE.MDF].[dbo].[DoorTable].[DoorTable_PK] AS [target]), OBJECT:([C:\DATABASE.MDF].[dbo].[DoorTable].[DoorTable_FI01] AS [target]), SET:(Insert, [C:\DATABASE.MDF].[dbo].[DoorTable].[Column1] as [target].[Column1] = [Expr1005],[C:\DATABASE.MDF].[dbo].[DoorTable].[Column2] as [target].[Column2] = [Expr1006],[C:\DATABASE.MDF].[dbo].[DoorTable].[Column3] as [target].[Column3] = [Expr1007],[C:\DATABASE.MDF].[dbo].[DoorTable].[Column4] as [target].[Column4] = [Expr1008],[C:\DATABASE.MDF].[dbo].[DoorTable].[Column5] as [target].[Column5] = [Expr1009],[C:\DATABASE.MDF].[dbo].[DoorTable].[Column6] as [target].[Column6] = [Expr1010],[C:\DATABASE.MDF].[dbo].[DoorTable].[Column7] as [target].[Column7] = [Expr1011],[C:\DATABASE.MDF].[dbo].[DoorTable].[Column8] as [target].[Column8] = [Expr1012],...
| |--Compute Scalar(DEFINE:([Action1004]=[Action1004], [Expr1198]=[Expr1198]))
| |--Top(TOP EXPRESSION:((1)))
| |--Compute Scalar(DEFINE:([Expr1198]=CASE WHEN [Action1004] = (1) THEN CASE WHEN [Expr1099] THEN (0) ELSE (1) END ELSE [Action1004] END))
| |--Compute Scalar(DEFINE:([Expr1005]=CONVERT_IMPLICIT(nvarchar(64),[@Column1],0), [Expr1006]=CONVERT_IMPLICIT(nvarchar(64),[@Column2],0), [Expr1007]=CONVERT_IMPLICIT(nvarchar(64),[@Column3],0), [Expr1008]=[@Column4], [Expr1009]=CONVERT_IMPLICIT(nvarchar(64),[@Column5],0), [Expr1010]=[@Column6], [Expr1011]=[@Column7], [Expr1012]=CONVERT_IMPLICIT(float(53),[@Column8],0),[Expr1099]=[Action1004]=(1) AND CASE WHEN [C:\DATABASE.MDF].[dbo].[DoorTable].[CarTable_Guid] as [target].[CarTable_Guid] = CONVERT_IMPLICIT(nvarchar(32),[@CarTable_Guid],0) THEN (1) ELSE (0) END))
| |--Compute Scalar(DEFINE:([Action1004]=ForceOrder(CASE WHEN [TrgPrb1002] IS NOT NULL THEN (1) ELSE (4) END)))
| |--Nested Loops(Left Outer Join)
| |--Constant Scan
| |--Compute Scalar(DEFINE:([TrgPrb1002]=(1)))
| |--Clustered Index Seek(OBJECT:([C:\DATABASE.MDF].[dbo].[DoorTable].[DoorTable_PK] AS [target]), SEEK:([target].[Guid]=CONVERT_IMPLICIT(nvarchar(1),[@Guid],0)) ORDERED FORWARD)
|--Clustered Index Seek(OBJECT:([C:\DATABASE.MDF].[dbo].[CarTable].[CarTable_PK]), SEEK:([C:\DATABASE.MDF].[dbo].[CarTable].[Guid]=[C:\DATABASE.MDF].[dbo].[DoorTable].[CarTable_Guid] as [target].[CarTable_Guid]) ORDERED FORWARD)
Решение 3
Я решил проблему, которую я имел. Что привело меня к тому, чтобы понять это, было посмотреть на проблему, которые эти парни имели: Перекомпилирование и планы исполнения Nhibernate
В основном, в коде .NET, он не определял свойство dbparameter.size. Поскольку различные размеры параметров приводят к созданию различных планов выполнения, каждая перестановка всех моих параметров вызывала разные планы для создания и кэширования.
Все, что мне нужно было сделать, было установить DBParameter.size до размера каждого соответствующего столбца из моих сценариев DDL! Вот это да.
Другие советы
Вместо того, чтобы делать это в петле 5000
раз, лучшая упаковка в хранимой процедуре, которая принимает TABLE
значений в качестве ввода и выполняют объемное обновление:
CREATE TYPE paramTable AS TABLE
(
guid UNIQUEIDENTIFIER NOT NULL PRIMARY KEY,
column1 INT,
column2 VARCHAR(100)
)
CREATE PROCEDURE prcMergeInput(@mytable paramTable)
AS
MERGE TestTable AS target
USING (
SELECT column1, column2, guid
FROM @mytable
) AS source
ON (target.Guid = source.Guid)
WHEN MATCHED THEN
UPDATE TestTable
SET Column1 = source.Column1,
Column2 = source.Column2
WHEN NOT MATCHED THEN
INSERT
INTO TestTable (Column1, Column2)
VALUES (source.Column1, source.Column2)
OUTPUT INSERTED.guid
Также убедитесь, что у вас есть указатель на TestTable (guid)
или это объявлено как PRIMARY KEY
.
Чтобы проверить источник кэшированных планов, вы можете запросить вид динамического управления, который содержит все кэшированные планы:
SELECT text
FROM sys.dm_exec_cached_plans
CROSS APPLY
sys.dm_exec_sql_text(plan_handle)
WHERE text LIKE ‘%SnippetFromYourQuery%’
И хотя похоже, что вы правильно параметризуете ваш запрос, вы можете проверить его, включив Принудительная параметризация:
alter database YourDb forced
Если это уменьшит время выполнения, вы должны исследовать, какую часть вашего запроса содержит жесткие значения, в отличие от параметров. SQL Profiler должен сделать это легко.