查看执行计划时，我们应该获得什么信息

　查看执行计划时，我们应该获得什么信息

　　当你的查询很慢时，你就应该看看预估的执行计划(当然也可以查看真实的执行计划)，找出耗时最多的操作，注意观察以下成本通常较高的操作：

　　1、表扫描(Table Scan)

　　当表没有聚集索引时就会发生，这时只要创建聚集索引或重整索引一般都可以解决问题。

　　2、聚集索引扫描(Clustered Index Scan)

　　有时可以认为等同于表扫描，当某列上的非聚集索引无效时会发生，这时只要创建一个非聚集索引就ok了。

　　3、哈希连接(Hash Join)

　　当连接两个表的列没有被索引时会发生，只需在这些列上创建索引即可。

　　4、嵌套循环(Nested Loops)

　　当非聚集索引不包括select查询清单的列时会发生，只需要创建覆盖索引问题即可解决。

　　5、RID查找(RID Lookup)

　　当你有一个非聚集索引，但相同的表上却没有聚集索引时会发生，此时数据库引擎会使用行ID查找真实的行，这时一个代价高的操作，这时只要在该表上创建聚集索引即可。

　　TSQL重构真实的故事

　　只有解决了实际的问题后，知识才转变为价值。当我们检查应用程序性能时，发现一个存储过程比我们预期的执行得慢得多，在生产数据库中检索一个月的销售数据居然要50秒，下面就是这个存储过程的执行语句：

　　exec uspGetSalesInfoForDateRange ‘1/1/2009’, 31/12/2009,’Cap’

　　Tom受命来优化这个存储过程，下面是这个存储过程的代码：

　ALTER PROCEDURE uspGetSalesInfoForDateRange

　　@startYear DateTime,

　　@endYear DateTime,

　　@keyword nvarchar(50)

　　AS

　　BEGIN

　　SET NOCOUNT ON;

　　SELECT

　　Name,

　　ProductNumber,

　　ProductRates.CurrentProductRate Rate,

　　ProductRates.CurrentDiscount Discount,

　　OrderQty Qty,

　　dbo.ufnGetLineTotal(SalesOrderDetailID) Total,

　　OrderDate,

　　DetailedDescription

　　FROM

　　Products INNER JOIN OrderDetails

　　ON Products.ProductID = OrderDetails.ProductID

　　INNER JOIN Orders

　　ON Orders.SalesOrderID = OrderDetails.SalesOrderID

　　INNER JOIN ProductRates

　　ON

　　Products.ProductID = ProductRates.ProductID

　　WHERE

　　OrderDate between @startYear and @endYear

　　AND

　　(

　　ProductName LIKE '' + @keyword + ' %' OR

　　ProductName LIKE '% ' + @keyword + ' ' + '%' OR

　　ProductName LIKE '% ' + @keyword + '%' OR

　　Keyword LIKE '' + @keyword + ' %' OR

　　Keyword LIKE '% ' + @keyword + ' ' + '%' OR

　　Keyword LIKE '% ' + @keyword + '%'

　　)

　　ORDER BY

　　ProductName

　　END

　　GO

分析索引

　　首先，Tom想到了审查这个存储过程使用到的表的索引，很快他发现下面两列的索引无故丢失了：

　　OrderDetails.ProductID

　　OrderDetails.SalesOrderID

　　他在这两个列上创建了非聚集索引，然后再执行存储过程：

　　exec uspGetSalesInfoForDateRange ‘1/1/2009’, 31/12/2009 with recompile

　　性能有所改变，但仍然低于预期(这次花了35秒)，注意这里的with recompile子句告诉SQL Server引擎重新编译存储过程，重新生成执行计划，以利用新创建的索引。

　　分析查询执行计划

　　Tom接下来查看了SQL Server Management Studio中的执行计划，通过分析，他找到了某些重要的线索：

　　1、发生了一次表扫描，即使该表已经正确设置了索引，而表扫描占据了总体查询执行时间的30%;

　　2、发生了一个嵌套循环连接。

　　Tom想知道是否有索引碎片，因为所有索引配置都是正确的，通过TSQL他知道了有两个索引都产生了碎片，很快他重组了这两个索引，于是表扫描消失了，现在执行存储过程的时间减少到25秒了。

　　为了消除嵌套循环连接，他又在表上创建了覆盖索引，时间进一步减少到23秒。

　　实施最佳实践

　　Tom发现有个UDF有问题，代码如下：　

ALTER FUNCTION [dbo].[ufnGetLineTotal]

　　(

　　@SalesOrderDetailID int

　　)

　　RETURNS money

　　AS

　　BEGIN

　　DECLARE @CurrentProductRate money

　　DECLARE @CurrentDiscount money

　　DECLARE @Qty int

　　SELECT

　　@CurrentProductRate = ProductRates.CurrentProductRate,

　　@CurrentDiscount = ProductRates.CurrentDiscount,

　　@Qty = OrderQty

　　FROM

　　ProductRates INNER JOIN OrderDetails ON

　　OrderDetails.ProductID = ProductRates.ProductID

　　WHERE

　　OrderDetails.SalesOrderDetailID = @SalesOrderDetailID

　　RETURN (@CurrentProductRate-@CurrentDiscount)*@Qty

　　END

　　在计算订单总金额时看起来代码很程序化，Tom决定在UDF的SQL中使用内联SQL。

　　dbo.ufnGetLineTotal(SalesOrderDetailID) Total -- 旧代码

　　(CurrentProductRate-CurrentDiscount)*OrderQty Total -- 新代码

　　执行时间一下子减少到14秒了。

　　在select查询清单中放弃不必要的Text列

　　为了进一步提升性能，Tom决定检查一下select查询清单中使用的列，很快他发现有一个Products.DetailedDescription列是Text类型，通过对应用程序代码的走查，Tom发现其实这一列的数据并不会立即用到，于是他将这一列从select查询清单中取消掉，时间一下子从14秒减少到6秒，于是Tom决定使用一个存储过程应用延迟加载策略加载这个Text列。

　　最后Tom还是不死心，认为6秒也无法接受，于是他再次仔细检查了SQL代码，他发现了一个like子句，经过反复研究他认为这个like搜索完全可以用全文搜索替换，最后他用全文搜索替换了like搜索，时间一下子降低到1秒，至此Tom认为调优应该暂时结束了。