理解SQL Server的SQL查询计划

阅览次数:
文章来源: a hear
原文作者: 不详
整理日期: 2007-04-07
发表评论

字体大小:
小
中
大

通过比较连接和子查询说明分支步骤

一条正确的老规则是：在结果集相同的情况下，连接比子查询具有更好的性能。

SELECT au_fname,au_lname

FROM authors

WHERE au_id IN (select au_id from titleauther ) 
StmtText

-------------------------------------------------------------------------------------------

|---Nested Loops(Inner Join, OUTER ReFERENCES:([titleauthor].[au_id])

|--Stream Aggregate(GROUP BY:([titleauthor].[au_id]))

| |--Index Scan(OBJECT:([pubs].[dbo].[titleauthor].[auidind]),ORDERED FORWARD)

|--ClusteredIndex Seek(OBJECT:([pubs].[dbo].[authors].[UPKCL_auidind]),
SEEK:([authors].[au_id]=[titleauthor].[au_id]) ORDERED FORWARD)
Table ‘authors’. Scan count 38,logical reads 76,physical reads 0,read-ahead reads 0.
Table  ‘titleauthor’. Scan count 2, logical reads 2, physical reads 1,read-ahead reads 0.

在这种情况下，查询引擎选择一个嵌套循环操作。这个查询被迫用聚集索引读取整个authors表，在处理中执行大量的逻辑页读。

注意：在带分支步骤的查询中，缩进行给你展示那些步骤是其它步骤的分支。

Select distinct au_fname,au_lname

From authors as a

Join titleauthor as t ON a.au_id=t.au_id
StmtText

---------------------------------------------------------------------------------
|--stream Aggregate(group by: ([a].[au_lname].[a].[au_fname]))

|-Nested loops(Inner Join,OUTER REFERENCES: ([a].[au_id]))

|-Index scan(OBJECT:([pubs].[dbo].[authors].[authord ]as[a]),ordered forward)

|-Index Seek (OBJECT: [pubs].[dbo].[titleauthor].[authord ]as [t]),
SEEK: ([t].[au_id]=[a].[au_id]) ORDER FORWARD)

Table ‘titleauthors’ .Scan count 23,logical reads 23,
physical reads 0,read ahead reads 0.
Table ‘authors’ .Scan count 1,logical reads 1,physical reads 0,read-ahead read 0.

上面的这个查询中，titleauthors表逻辑读的数字上升而authors表下降。注意到，stream aggregation在查询计划中位置更高，即发生的更晚。

比较查询计划

可以使用查询计划比较两个不同查询的相对效果。如，你可能想知道是否一个查询比另一个查询增加了额外的开销或者选择了不同的索引策略。

在这个例子中，我们比较两个查询。第一个使用SUBSTRING第二个使用LIKE。

Select *

From authors

Where substring(au_lname,1,2)=’Wh’
StmtText

--------------------------------------------------------------
|--Clustered

Index  Scan(OBJECT: ([pubs].[dbo].[authors].[UPKCL_auidind])
Where: (substring([authors].[au_lname],1,2)=’Wh’))

与使用LIKE的相似查询相比较：

Select * 

From authors

Where au_lname like ‘Wh%’
StmtText

-------------------------------------------------------------------------

|-Bookmark Lookup(BOOKMARK: ([Bmk1000]),OBJECT: ([pubs].[dbo].[authors]))

|-Index Seek(OBJECT:([pubs].[dbo].[authors].[sunmind]), 
SEEk:([authors].[au_lname]>=’WGp’ AND [authors].[au_lname]<’WI’),
WHERE:(like([authors].[au_lname],’Wh%’,NULL)) ORDERED FORWARD)

很明显，第二个查询使用INDEX SEEK操作，第一个查询使用了CLUSTERED INDEX SCAN操作，第二个查询计划比第一个更简单。

当我们比较查询计划中那一个最好时，事实上我们更愿意用SET STATISTICS PROFILE ON或SQL Query Analyzer的Graphic Execution Plan(图形执行计划)特性而不是SET SHOWPLAN_TEXT ON。这些工具将以百分率的方式明确给你展示每一个查询计划步骤的处理消耗。这可以告诉你每种选择的或多或少的查询消耗情况。你还可以同时运行两个或更多查询来看哪个执行的最好。

为了获得最全面的性能测量信息，使用SET STATISTICS IO 和SET STATISTICS TIME也是很重要的。

[1] [2] [3]

上一篇:PHP使用zlib扩展实现页面GZIP压缩输出
下一篇:构建支持Master/Slave读写分离的数据库操作类

推荐文章

热点文章

相关文章

百度搜索

理解SQL Server的SQL查询计划

网友评论: