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

最新推荐文章于 2025-08-13 17:52:41 发布

weixin_33852020

最新推荐文章于 2025-08-13 17:52:41 发布

阅读量104

点赞数

CC 4.0 BY-SA版权

文章标签：数据库

原文链接：http://www.cnblogs.com/wangyhua/p/4050546.html

本文介绍了一种通过审查和优化SQL查询来提高数据库性能的方法。针对一个执行缓慢的存储过程，通过分析执行计划、修复缺失索引、消除表扫描、解决嵌套循环连接问题，并重构UDF，最终将执行时间从50秒降低到1秒。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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

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

　　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认为调优应该暂时结束了。

转载于:https://www.cnblogs.com/wangyhua/p/4050546.html