Я использую следующую технику, чтобы примерно оценить прошедшее время выполнения хранимой процедуры с помощью SSMS (SQL Server Management Studio):Зачем DATEDIFF удвоить результат после первого выполнения?
USE [MyDB]
GO
DECLARE @t1 DATETIME;
DECLARE @t2 DATETIME;
SET @t1 = GETDATE();
DECLARE @TTIdsList dbo.TTIdsList_ident
INSERT INTO @TTIdsList(Id)
VALUES (7890137988314100)
DECLARE @return_value int
EXEC @return_value = [mySCH].[DataLoadByList]
@CaseIds = @TTIdsList
SELECT 'Return Value' = @return_value
SET @t2 = GETDATE();
SELECT DATEDIFF(microsecond,@t1,@t2) AS elapsed_us;
GO
Он работает хорошо, но она возвращает другой результат на первом исполнении (3000 микросекунд) , Во всех последующих исполнениях он возвращается в два раза: 6000 микросекунд.
Я что-то упустил, так как эти переменные инициализируются? Если да, то что мне не хватает?
Это, вероятно, время компиляции для хранимой процедуры вы используете. чтобы проверить это предложение, переместите 'SET @ t1' справа перед' EXEC ... 'и 'SET @ t2' вправо после него и посмотрите, что произойдет. –
@ ZoharPeled Я сделал точно так, как вы сказали, и я все равно получаю те же результаты: 3000 микросекунд в первый раз, 6000 микросекунд для 2-го, 3-го, 4-го и любого последующего запуска. BTW, каждый раз, когда я переименую 'elapsed_us', он возвращается к 3000 микросекундам (что, я считаю, является правильным значением). Weird. – datps
Так что это время компиляции хранимой процедуры. чтобы подтвердить, что вы можете добавить подсказку 'RECOMPILE' в хранимой процедуре. Если я прав, вы увидите, что время теперь стабильно на 3000 микросекунд. –