SQL Server 存储过程性能测试

Posted 2023-03-28

【中文标题】SQL Server 存储过程性能测试

【英文标题】：SQL Server stored procedure performance testing

【发布时间】：2014-06-01 19:44:31

【问题描述】：

我有一个任务是在 SQL Server 中测试存储过程的性能。我的目标是向利益相关者报告存储过程执行时间的平均时间和标准偏差。真实的数据输入在这里是必须的:)

我的问题：当我尝试实际进行测试时，我创建了一个简单的脚本，据说应该测量执行存储过程所需的时间：

DECLARE @ValidCharacters varchar(20), 
        @DataLength tinyint, @LocalPart smallint, @DomainPart smallint

SET @ValidCharacters = 'abcdefghijklmnopqrstuvwxy'
SET @DataLength = DATALENGTH (@ValidCharacters) - 1

CREATE TABLE #LocalTempTable(EmailID int PRIMARY KEY IDENTITY(1,1), email varchar(30));

CREATE TABLE #LocalTempTableTimesOfInserting(TimesOfInsertingID int PRIMARY KEY IDENTITY(1,1), TimesOfInserting int);

DECLARE @counter int, @boundary int, @email varchar(25), @start DateTime, @end DateTime

SET @counter=0
SET @boundary=25

WHILE (@counter < @boundary)
BEGIN
    DBCC FREEPROCCACHE;
    DBCC DROPCLEANBUFFERS;

    SET @email = SUBSTRING(@ValidCharacters, ABS(CHECKSUM(NewId())) % @DataLength + 1, ABS(CHECKSUM(NewId())) % @DataLength + 1) + 
                 '@' + SUBSTRING(@ValidCharacters, ABS(CHECKSUM(NewId())) % @DataLength + 1, ABS(CHECKSUM(NewId())) % @DataLength + 1) + '.com'
SET @start = SYSDATETIME()

    INSERT INTO #LocalTempTable VALUES (@email);

SET @end = SYSDATETIME()

INSERT INTO #LocalTempTableTimesOfInserting 
    VALUES (DATEDIFF(ns, @start, @end));

    SELECT DATEDIFF(ms, @start, @end)

    SET @counter = @counter + 1;
END

您看到我正在对插入进行微基准测试并将结果记录到本地临时表中（我的想法是导出后者以表现出色并在那里进行计算并与同事分享）:)

我的问题：

1234563这样做测试，主要是针对我这里的有趣问题）；

为什么在这种情况下我会得到无用的结果，就像这样（以纳秒为单位测量） - 也许随着操作开始变得简单和快速，我会看到这种波动的性能，结果不稳定？或者这可能是 SQL Server 返回缓存结果的结果（即使我使用的是 DBCC；那么如何将其关闭？）。另一种解释可能是线程和并行执行（不同的线程正在执行时间函数，因此它们正在并行执行它们 - 这将解释零）：

【问题讨论】：

变量为datetime。那只有1/300 一秒的精度，而不是纳秒！而且系统时间函数也没有那么准确。

您在这里问了两个不同的问题...重新措辞并将第一个关于如何编写 sp 性能测试的指导问题拆分为另一个问题可能会帮助您获得更好的答案。

@MartinSmith :: 1/300 (s) 对于更大的存储过程来说非常好。但不是为了一个轻量级的——关于这个特定点的任何建议？我怎样才能更精确？

datetime2(7) 具有更高的精度。系统时间功能的分辨率仍然是一个问题。我会测试数千或数百万次处决并取平均值。不仅仅是单次执行。

@MartinSmith ，是的，我计划同时进行数据生成和性能测试，对 SP 的调用次数将达到数百万。感谢 datetime2 :)

【参考方案1】：

回答你的第二个问题：就像你说的，这可能是查询执行计划缓存的结果。

Execution Plan Caching and Reuse

当您手动运行 sp 并且它运行得很快时，您可以尝试执行另一个查询，然后再次运行您的 sp 测试。如果第二次运行速度较慢，则您的速度可能是由于缓存所致。