五种提升SQL性能的方法

原文地址

五种提升 SQL 性能的方法
发布日期： 4/1/2004 | 更新日期： 4/1/2004
Johnny Papa
Data Points Archive
有时， 为了让应用程序运行得更快，所作的所有工做就是在这里或那里作一些很小调整。啊，但关键在于肯定如何进行调整！早晚您会遇到这种状况：应用程序中的 SQL 查询不能按照您想要的方式进行响应。它要么不返回数据，要么耗费的时间长得出奇。若是它下降了报告或您的企业应用程序的速度，用户必须等待的时间过长，他们就会很不满意。就像您的父母不想听您解释为何在深更半夜才回来同样，用户也不会听你解释为何查询耗费这么长时间。（“对不起，妈妈，我使用了太多的 LEFT JOIN。”）用户但愿应用程序响应迅速，他们的报告可以在瞬间以内返回分析数据。就我本身而言，若是在 Web 上冲浪时某个页面要耗费十多秒才能加载（好吧，五秒更实际一些），我也会很不耐烦。
为了解决这些问题，重要的是找到问题的根源。那么，从哪里开始呢？根本缘由一般在于数据库设计和访问它的查询。在本月的专栏中，我将讲述四项技术，这些技术可用于提升基于 SQL Server? 的应用程序的性能或改善其可伸缩性。我将仔细说明 LEFT JOIN、CROSS JOIN 的使用以及 IDENTITY 值的检索。请记住，根本没有神奇的解决方案。调整您的数据库及其查询须要占用时间、进行分析，还须要大量的测试。这些技术都已被证实行之有效，但对您的应用程序而言，可能其中一些技术比另外一些技术更适用。
*
本页内容

从 INSERT 返回 IDENTITY
            从 INSERT 返回 IDENTITY

            内嵌视图与临时表
            内嵌视图与临时表

            避免 LEFT JOIN 和 NULL
            避免 LEFT JOIN 和 NULL

            灵活使用笛卡尔乘积
            灵活使用笛卡尔乘积

            拾遗补零
            拾遗补零

从 INSERT 返回 IDENTITY
我决定从遇到许多问题的内容入手：如何在执行 SQL INSERT 后检索 IDENTITY 值。一般，问题不在于如何编写检索值的查询，而在于在哪里以及什么时候进行检索。在 SQL Server 中，下面的语句可用于检索由最新在活动数据库链接上运行的 SQL 语句所建立的 IDENTITY 值：
SELECT @@IDENTITY
这个 SQL 语句并不复杂，但须要记住的一点是：若是这个最新的 SQL 语句不是 INSERT，或者您针对非 INSERT SQL 的其余链接运行了此 SQL，则不会得到指望的值。您必须运行下列代码才能检索紧跟在 INSERT SQL 以后且位于同一链接上的 IDENTITY，以下所示：
INSERT INTO Products (ProductName) VALUES ('Chalk')

SELECT @@IDENTITY
在一个链接上针对 Northwind 数据库运行这些查询将返回一个名称为 Chalk 的新产品的 IDENTITY 值。因此，在使用 ADO 的 Visual Basic? 应用程序中，能够运行如下语句：
Set oRs = oCn.Execute("SET NOCOUNT ON;INSERT INTO Products _
(ProductName) VALUES ('Chalk');SELECT @@IDENTITY")

lProductID = oRs(0)
此代码告诉 SQL Server 不要返回查询的行计数，而后执行 INSERT 语句，并返回刚刚为这个新行建立的 IDENTITY 值。SET NOCOUNT ON 语句表示返回的记录集有一行和一列，其中包含了这个新的 IDENTITY 值。若是没有此语句，则会首先返回一个空的记录集（由于 INSERT 语句不返回任何数据），而后会返回第二个记录集，第二个记录集中包含 IDENTITY 值。这可能有些使人困惑，尤为是由于您历来就没有但愿过 INSERT 会返回记录集。之因此会发生此状况，是由于 SQL Server 看到了这个行计数（即一行受到影响）并将其解释为表示一个记录集。所以，真正的数据被推回到了第二个记录集。固然您可使用 ADO 中的 NextRecordset 方法获取此第二个记录集，但若是总可以首先返回该记录集且只返回该记录集，则会更方便，也更有效率。
此方法虽然有效，但须要在 SQL 语句中额外添加一些代码。得到相同结果的另外一方法是在 INSERT 以前使用 SET NOCOUNT ON 语句，并将 SELECT @@IDENTITY 语句放在表中的 FOR INSERT 触发器中，以下面的代码片断所示。这样，任何进入该表的 INSERT 语句都将自动返回 IDENTITY 值。
CREATE TRIGGER trProducts_Insert ON Products FOR INSERT AS
SELECT @@IDENTITY
GO
触发器只在 Products 表上发生 INSERT 时启动，因此它老是会在成功 INSERT 以后返回一个 IDENTITY。使用此技术，您能够始终以相同的方式在应用程序中检索 IDENTITY 值。
返回页首返回页首
内嵌视图与临时表
某些时候，查询须要将数据与其余一些可能只能经过执行 GROUP BY 而后执行标准查询才能收集的数据进行联接。例如，若是要查询最新五个定单的有关信息，您首先须要知道是哪些定单。这可使用返回定单 ID 的 SQL 查询来检索。此数据就会存储在临时表（这是一个经常使用技术）中，而后与 Products 表进行联接，以返回这些定单售出的产品数量：
CREATE TABLE #Temp1 (OrderID INT NOT NULL, _
OrderDate DATETIME NOT NULL)

INSERT INTO #Temp1 (OrderID, OrderDate)
SELECT TOP 5 o.OrderID, o.OrderDate
FROM Orders o ORDER BY o.OrderDate DESC

SELECT p.ProductName, SUM(od.Quantity) AS ProductQuantity
FROM #Temp1 t
INNER JOIN [Order Details] od ON t.OrderID = od.OrderID
INNER JOIN Products p ON od.ProductID = p.ProductID
GROUP BY p.ProductName
ORDER BY p.ProductName

DROP TABLE #Temp1
这些 SQL 语句会建立一个临时表，将数据插入该表中，将其余数据与该表进行联接，而后除去该临时表。这会致使此查询进行大量 I/O 操做，所以，能够从新编写查询，使用内嵌视图取代临时表。内嵌视图只是一个能够联接到 FROM 子句中的查询。因此，您不用在 tempdb 中的临时表上耗费大量 I/O 和磁盘访问，而可使用内嵌视图获得一样的结果：
SELECT p.ProductName,
SUM(od.Quantity) AS ProductQuantity
FROM (
SELECT TOP 5 o.OrderID, o.OrderDate
FROM Orders o
ORDER BY o.OrderDate DESC
) t
INNER JOIN [Order Details] od ON t.OrderID = od.OrderID
INNER JOIN Products p ON od.ProductID = p.ProductID
GROUP BY
p.ProductName
ORDER BY
p.ProductName
此查询不只比前面的查询效率更高，并且长度更短。临时表会消耗大量资源。若是只须要将数据联接到其余查询，则能够试试使用内嵌视图，以节省资源。
返回页首返回页首
避免 LEFT JOIN 和 NULL
固然，有不少时候您须要执行 LEFT JOIN 和使用 NULL 值。可是，它们并不适用于全部状况。改变 SQL 查询的构建方式可能会产生将一个花几分钟运行的报告缩短到只花几秒钟这样的天壤之别的效果。有时，必须在查询中调整数据的形态，使之适应应用程序所要求的显示方式。虽然 TABLE 数据类型会减小大量占用资源的状况，但在查询中还有许多区域能够进行优化。SQL 的一个有价值的经常使用功能是 LEFT JOIN。它能够用于检索第一个表中的全部行、第二个表中全部匹配的行、以及第二个表中与第一个表不匹配的全部行。例如，若是但愿返回每一个客户及其定单，使用 LEFT JOIN 则能够显示有定单和没有定单的客户。
此工具可能会被过分使用。LEFT JOIN 消耗的资源很是之多，由于它们包含与 NULL（不存在）数据匹配的数据。在某些状况下，这是不可避免的，可是代价可能很是高。LEFT JOIN 比 INNER JOIN 消耗资源更多，因此若是您能够从新编写查询以使得该查询不使用任何 LEFT JOIN，则会获得很是可观的回报（请参阅图 1 中的图）。

图 1：查询
加快使用 LEFT JOIN 的查询速度的一项技术涉及建立一个 TABLE 数据类型，插入第一个表（LEFT JOIN 左侧的表）中的全部行，而后使用第二个表中的值更新 TABLE 数据类型。此技术是一个两步的过程，但与标准的 LEFT JOIN 相比，能够节省大量时间。一个很好的规则是尝试各类不一样的技术并记录每种技术所需的时间，直到得到用于您的应用程序的执行性能最佳的查询。
测试查询的速度时，有必要屡次运行此查询，而后取一个平均值。由于查询（或存储过程）可能会存储在 SQL Server 内存中的过程缓存中，所以第一次尝试耗费的时间好像稍长一些，而全部后续尝试耗费的时间都较短。另外，运行您的查询时，可能正在针对相同的表运行其余查询。当其余查询锁定和解锁这些表时，可能会致使您的查询要排队等待。例如，若是您进行查询时某人正在更新此表中的数据，则在更新提交时您的查询可能须要耗费更长时间来执行。
避免使用 LEFT JOIN 时速度下降的最简单方法是尽量多地围绕它们设计数据库。例如，假设某一产品可能具备类别也可能没有类别。若是 Products 表存储了其类别的 ID，而没有用于某个特定产品的类别，则您能够在字段中存储 NULL 值。而后您必须执行 LEFT JOIN 来获取全部产品及其类别。您能够建立一个值为“No Category”的类别，从而指定外键关系不容许 NULL 值。经过执行上述操做，如今您就可使用 INNER JOIN 检索全部产品及其类别了。虽然这看起来好像是一个带有多余数据的变通方法，但多是一个颇有价值的技术，由于它能够消除 SQL 批处理语句中消耗资源较多的 LEFT JOIN。在数据库中所有使用此概念能够为您节省大量的处理时间。请记住，对于您的用户而言，即便几秒钟的时间也很是重要，由于当您有许多用户正在访问同一个联机数据库应用程序时，这几秒钟实际上的意义会很是重大。
返回页首返回页首
灵活使用笛卡尔乘积
对于此技巧，我将进行很是详细的介绍，并提倡在某些状况下使用笛卡尔乘积。出于某些缘由，笛卡尔乘积 (CROSS JOIN) 遭到了不少谴责，开发人员一般会被警告根本就不要使用它们。在许多状况下，它们消耗的资源太多，从而没法高效使用。可是像 SQL 中的任何工具同样，若是正确使用，它们也会颇有价值。例如，若是您想运行一个返回每个月数据（即便某一特定月份客户没有定单也要返回）的查询，您就能够很方便地使用笛卡尔乘积。 图 2 中的 SQL 就执行了上述操做。
虽然这看起来好像没什么神奇的，可是请考虑一下，若是您从客户到定单（这些定单按月份进行分组并对销售额进行小计）进行了标准的 INNER JOIN，则只会得到客户有定单的月份。所以，对于客户未订购任何产品的月份，您不会得到 0 值。若是您想为每一个客户都绘制一个图，以显示每月和该月销售额，则可能但愿此图包括月销售额为 0 的月份，以便直观标识出这些月份。若是使用 图 2 中的 SQL，数据则会跳过销售额为 0 美圆的月份，由于在定单表中对于零销售额不会包含任何行（假设您只存储发生的事件）。
图 3 中的代码虽然较长，可是能够达到获取全部销售数据（甚至包括没有销售额的月份）的目标。首先，它会提取去年全部月份的列表，而后将它们放入第一个 TABLE 数据类型表 (@tblMonths) 中。下一步，此代码会获取在该时间段内有销售额的全部客户公司的名称列表，而后将它们放入另外一个 TABLE 数据类型表 (@tblCus-tomers) 中。这两个表存储了建立结果集所必需的全部基本数据，但实际销售数量除外。 第一个表中列出了全部月份（12 行），第二个表中列出了这个时间段内有销售额的全部客户（对于我是 81 个）。并不是每一个客户在过去 12 个月中的每月都购买了产品，因此，执行 INNER JOIN 或 LEFT JOIN 不会返回每月的每一个客户。这些操做只会返回购买产品的客户和月份。
笛卡尔乘积则能够返回全部月份的全部客户。笛卡尔乘积基本上是将第一个表与第二个表相乘，生成一个行集合，其中包含第一个表中的行数与第二个表中的行数相乘的结果。所以，笛卡尔乘积会向表 @tblFinal 返回 972 行。最后的步骤是使用此日期范围内每一个客户的月销售额总计更新 @tblFinal 表，以及选择最终的行集。
若是因为笛卡尔乘积占用的资源可能会不少，而不须要真正的笛卡尔乘积，则能够谨慎地使用 CROSS JOIN。例如，若是对产品和类别执行了 CROSS JOIN，而后使用 WHERE 子句、DISTINCT 或 GROUP BY 来筛选出大多数行，那么使用 INNER JOIN 会得到一样的结果，并且效率高得多。若是须要为全部的可能性都返回数据（例如在您但愿使用每个月销售日期填充一个图表时），则笛卡尔乘积可能会很是有帮助。可是，您不该该将它们用于其余用途，由于在大多数方案中 INNER JOIN 的效率要高得多。
拾遗补零
这里介绍其余一些可帮助提升 SQL 查询效率的经常使用技术。假设您将按区域对全部销售人员进行分组并将他们的销售额进行小计，可是您只想要那些数据库中标记为处于活动状态的销售人员。您能够按区域对销售人员分组，并使用 HAVING 子句消除那些未处于活动状态的销售人员，也能够在 WHERE 子句中执行此操做。在 WHERE 子句中执行此操做会减小须要分组的行数，因此比在 HAVING 子句中执行此操做效率更高。HAVING 子句中基于行的条件的筛选会强制查询对那些在 WHERE 子句中会被去除的数据进行分组。
另外一个提升效率的技巧是使用 DISTINCT 关键字查找数据行的单独报表，来代替使用 GROUP BY 子句。在这种状况下，使用 DISTINCT 关键字的 SQL 效率更高。请在须要计算聚合函数（SUM、COUNT、MAX 等）的状况下再使用 GROUP BY。另外，若是您的查询老是本身返回一个惟一的行，则不要使用 DISTINCT 关键字。在这种状况下，DISTINCT 关键字只会增长系统开销。
您已经看到了，有大量技术均可用于优化查询和实现特定的业务规则，技巧就是进行一些尝试，而后比较它们的性能。最重要的是要测试、测试、再测试。在此专栏的未来各期内容中，我将继续深刻讲述 SQL Server 概念，包括数据库设计、好的索引实践以及 SQL Server 安全范例。
若有向 Johnny 提出的问题和建议，请发送电子邮件到 mmdata@microsoft.com
Johnny Papa 是北卡罗来纳州罗利市的 MJM 研究公司的信息技术副总裁，他著有?Professional ADO 25 RDS Programming with ASP 30?? (Wrox, 2000)，并常常在行业会议中作演讲。要与他联系，请发送电子邮件到 datapoints@lancelotweb.com
摘自 MSDN Magazine 2002 年 7 月 刊。能够在您当地的报摊上购买此杂志，但最好当即 订阅
转到原英文页面