Question

在MS-SQL中测量SQL性能的方法是否比使用Profiler更简单？

我一直在使用我在互联网上找到的这个脚本，它给了我测量，但我不知道它有多准确。

DECLARE @StartTime datetime;

DBCC DROPCLEANBUFFERS  -- Force data/index pages out of buffer cache for valid test
SET @StartTime = GETDATE() -- Measurement Starts  

-->Insert SQL CALL/Script here

-- Measurement Ends  
SELECT ExecutionTimeInMS = DATEDIFF(millisecond, @StartTime, getdate())
GO

是否有类似的替代方案可以在我正在做出的选择上获得快速，肮脏，通常准确的脉冲？

它已经返回了一些令人惊讶的结果，但是我不知道在测试查询或测试工具/脚本中引发意外？

Answer 1

这是我的测试设置：

DBCC DROPCLEANBUFFERS
DBCC freeproccache

SET STATISTICS IO ON
SET STATISTICS TIME ON

SELECT * FROM sys.all_columns

为您提供了良好的输出（在消息选项卡上）：

(4307 row(s) affected)
Table 'syscolrdb'. Scan count 1, logical reads 167, physical reads 0, read-ahead reads 167, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'syscolpars'. Scan count 1, logical reads 12, physical reads 1, read-ahead reads 10, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
   CPU time = 78 ms,  elapsed time = 738 ms.

Answer 2

在删除缓冲区之前，您应该设置checkpoint以强制所有脏页到磁盘。无论如何，在测试系统中播放时，可以选择丢弃缓冲区。 SQL查询的性能在很大程度上取决于数据库中的数据以及在该数据库上运行的查询的类型，频率，参数和结果集。

在“干净”的单用户系统上运行查询会为干净的单用户系统生成结果。缓冲区管理是DBMS的核心功能，所以我没有看到任意刷新缓冲区和测量执行时间值的要点。此外，在生产系统上执行此操作可能会降低整体性能，因此也会影响要测试的查询。

要优化单个查询，请使用执行计划并识别查询中占据最高份额的部分，并查看您是否可以对其执行任何操作。例如，如果您设计的索引设计不合适，那么执行时间将只是执行计划会给您一个提示。

要识别值得优化工作的查询，请使用分析器查找a）消耗资源的查询（例如，长时间运行）和b）经常使用的查询。

要监控整个系统，请使用性能计数器，并关注内存和I / O子系统，例如：分页计数器。

无需使用分析器即可测量SQL性能

2 个答案: