理解SQL Server的SQL查询计划--.doc

　　理解SQL Server的SQL查询计划 　　本文通过详细分析一个示例来说明SEEK、SCAN等操作的用法和效果，供大家参考！ 　　入门指南 　　让我们以一个简单的例子帮助你理解如何阅读查询计划，可以通过发出SET SHO big_sales SELECT ord_date FROM big_sales StmtText ------------------------------------------------------------------------- |--ClusteredIndexScan(OBJECT:([pubs].[dbo].[big_sales].[UPKCL_big_sales]))　　上面的查询展示返回的数据量非常不同，所以小结果集(ord_date)的查询比其它查询运行更快，这只是因为存在大量底层的I/O。然而，这两个查询计划实际上是一样的。你可以通过使用其它索引提高性能。例如，在title_id列上有一个非聚集索引存在： SELECT title_id FROM big_sales StmtText ------------------------------------------------------------------ |--Index Scan(OBJECT:([pubs].[dbo].[big_sales].[ndx_sales_ttlID]))　　上面的查询的执行时间与SELECT *查询相比非常小，这是因为可以从非聚集索引即可得到所有结果。该类查询被称为covering query（覆盖查询），因为全部结果集被一个非聚集索引所覆盖。 　　SEEK与SCAN 　　第一件事是你需要在查询计划中区别SEEK和SCAN操作的不同。 　　注意：一个简单但非常有用的规则是SEEK操作是有效率的，而SCAN操作即使不是非常差，其效率也不是很好。SEEK操作是直接的，或者至少是快速的，而SCAN操作需要对整个对象进行读取（表，聚集索引或非聚集索引）。因此，SCAN操作通常比SEEK要消耗更多的资源。如果你的查询计划仅是扫描操作，你就应该考虑调整你的查询了。 　　 big_sales tText -----------------------------------------------------------------------------|--Clustered Index Seek(OBJECT: ([pubs].[dbo].[big_sales].[UPKCL_big_sales])), SEEK: ([big_sales].[stor_id]={1} ORDERED FOR big_sales tText ------------------------------------------------------------------------------|-Clustered Index Seek(OBJECT: ([pubs].[dbo].[big_sales].[UPKCL_big_sales] ), SEEK: ([big_sales].[stor_id]gt;=7131) ORDER FOR big_sales Where stor_id bettText ------------------------------------------------------------------------------|-Clustered Index Seek(OBJECT: ([pubs].[dbo].[big_sales].[UPKCL_big_sales] ), SEEK:([big_sales].[stor_id]gt;=7066 and ([big_sales].[stor_id]lt;=7131) ORDER FORWARD)　　这个看起来也一样。只是查找谓词改变了。因为查找是非常快的，所以这个查询是相当好的。 　　SEEK和SCAN也可包含Where谓词。在这种情况下，这个谓词告诉你Where子句从结果集中过滤出哪些记录。因为它是作为SEEK或SCAN的一个组件执行的， Where子句通常既不损害也不提高这个操作本身的性能。Whe 1234下一页 这篇文章来自..，。re子句会帮助查询优化器找到可能有最佳性能的索引。 　　查询优化的一个重要部分是要确定是否在某个索引上执行SEEK操作，如果是这样，就找到了具有最佳性能的索引。大部分情况下，查询引擎能出色地查找到存在的索引。但是，目前有三种涉及到索引的常见问题： 　　◆数据库设计师，通常是应用开发者，在表中没有建立任何索引。 　　◆数据库设计师通常猜测不到常用的查