SQL Server如何比较简单查询的速度

Question

我有一个很大的查询，我试图改进它的一部分，但由于缓存机制和t-sql代码的简单性，我没有可靠的环境来测试速度。我想要提高速度的查询全部持续大约1或2秒，所以我看不出明显的差别。为每个比较创建虚拟数据需要太多时间。你建议我做什么？我正在使用我的公司数据库，所以每次删除缓存都可能是有害的，我猜。

编辑： 看完所有的评论后，我做了一些评论，并有一些想法。但在统计数据中查看所有这些值是否正是我想要的？

这里是我所面临的问题：

执行计划：首先，我运行一些查询，看着执行计划，在顶部 - 查询成本（相对于批）我不能得到一个价值不是0.00％。即使我的查询持续超过1分钟。只有我得到的是0.00％。并根据图表，所有的值为0％

DB统计。现在我正在测试两个查询。其中之一是

SELECT * FROM MY_TABLE /* WHERE
my_primarykey LIKE '％ht_atk％' */

，第二个是评论的免费版本。

SELECT * FROM MY_TABLE WHERE
my_primarykey LIKE '％ht_atk％'

这里从数据库统计我的结果，第一次查询：。

Application Profile Statistics  
    Timer resolution (milliseconds) 0 0 
    Number of INSERT, UPDATE, DELETE statements 0 0 
    Rows effected by INSERT, UPDATE, DELETE statements 0 0 
    Number of SELECT statements 2 2 
    Rows effected by SELECT statements 16387 15748,4 
    Number of user transactions 7 6,93182 
    Average fetch time 0 0 
    Cumulative fetch time 0 0 
    Number of fetches 0 0 
    Number of open statement handles 0 0 
    Max number of opened statement handles 0 0 
    Cumulative number of statement handles 0 0 

Network Statistics  
    Number of server roundtrips 3 3 
    Number of TDS packets sent 3 3 
    Number of TDS packets received 252 242,545 
    Number of bytes sent 868 861,091 
    Number of bytes received 1,01917e+006 981160 

Time Statistics  
    Cumulative client processing time 0 0,204545 
    Cumulative wait time on server replies 25 10,0455 

第二个查询：

Application Profile Statistics  
    Timer resolution (milliseconds) 0 0 
    Number of INSERT, UPDATE, DELETE statements 0 0 
    Rows effected by INSERT, UPDATE, DELETE statements 0 0 
    Number of SELECT statements 2 2 
    Rows effected by SELECT statements 14982 15731,3 
    Number of user transactions 5 6,88889 
    Average fetch time 0 0 
    Cumulative fetch time 0 0 
    Number of fetches 0 0 
    Number of open statement handles 0 0 
    Max number of opened statement handles 0 0 
    Cumulative number of statement handles 0 0 

Network Statistics  
    Number of server roundtrips 3 3 
    Number of TDS packets sent 3 3 
    Number of TDS packets received 230 242,267 
    Number of bytes sent 752 858,667 
    Number of bytes received 932387 980076 

Time Statistics  
    Cumulative client processing time 1 0,222222 
    Cumulative wait time on server replies 8 10 

我每次执行，该值是随机变化的，我不能够赶上一个很好的观点哪个查询速度更快。

最后当我做到这一点：

SET STATISTICS TIME ON SET STATISTICS IO ON

两个查询，结果是一样的。

表'my_TABLE'。扫描计数1，逻辑读取682，物理读取0，预读读取0.

因此，我再次无法对这两个查询进行比较。如何解释结果？我在找错地方吗？我如何比较以上两个简单查询？

Answer 1

运行set statistics time on和set statistics io on，然后在文本模式下运行大查询。您可以在要优化的查询的每个部分之后放置一些打印件。

你会得到线，如：

Table 'Table'. Scan count 1, logical reads 10, physical reads 0, read-ahead reads 0, lob logical reads 387, lob physical reads 0, lob read-ahead reads 0. 

尽量把表中的一些数据，并检查扫描计数和逻辑读取大的数字。

您也可以检查实际执行计划并搜索任何聚集索引扫描。这可能表明某个表中缺少索引。

Answer 2

使用query analyzer找出查询中的昂贵部分（这取决于数据库统计数据，因此请使用代表性数据）。

这样可以让您调整要优化的零件。

尝试用秒表计时或查看结果返回到SSMS所需的时间，最多只能猜测。

Answer 3

好方法太看执行平淡。它告诉我们如何执行查询以及大部分时间需要什么。你甚至可以决定在该基础上创建索引。它特别适用于大型查询。 SQLServer大多数时候都会找到执行查询的最佳方式，但是您可以通过为其提供在WHERE和JOIN语句中使用的字段索引来改进它。如果您无法读取像估计成本和时间图表一样的平滑执行，您可以从MSDN详细阅读它。

Answer 4

正如@affan所说，最好的方法是使用执行计划给出的信息。但你总是可以建立与代码一个简单的计数器一样

IF @debug > 0 BEGIN 
    DECLARE @now DATETIME; 
    SET @now = CURRENT_TIMESTAMP; 
END 

和

IF @debug > 0 BEGIN 
    SELECT DATEDIFF(ms,@now,CURRENT_TIMESTAMP)/1000.0 AS Runtime; 
END 

Answer 5

在查询分析器去查询>包括实际的执行计划和查询>包括客户端统计。

使用执行计划来确定查询中成本最高的部分。当您将鼠标移到或点击任何节点时，它会显示一整组统计信息。尝试查看是否可以重新加入连接或过滤器以减少返回的行数。

使用客户端统计来比较两个查询。每次运行查询时，它都会在客户端统计信息页面添加一个新列。你想看看最后一组：时间统计。

我知道其中的一些显而易见，但下面是一些减少负载的常用提示： 仅返回所需的列。有时候人们会返回所有列，或者他们用于编码的一些标识符列，但最终用户不需要。 - 对于每个表 - 减少返回的行数。 - 不必在不使用临时表时。这会导致“双倍下降”，或者多次查询同一个非常大的表。