存储过程对应用程序性能的影响

优化数据库性能


存储过程对应用程序性能的影响
所有设计优良的 Microsoft? SQL Server? 2000 应用程序都应当使用存储过程。不论是否将应用程序的业务逻辑写入存储过程都应如此。甚至连没有业务逻辑组件的标准 Transact-SQL 语句，在用参数打包成存储过程后也能获得性能收益。编译进存储过程的 Transact-SQL 语句在执行时可省去大量的处理。有关更多信息，请参见存储过程。

存储过程的另一个优点是客户端执行请求使用网络的效率比将等效的 Transact-SQL 语句发送到服务器高。例如，假设应用程序需要将一个大的二进制值插入 image 数据列。为使用 INSERT 语句发送数据，该应用程序必须将该二进制值转换为字符串（其大小翻倍），然后发送到服务器。服务器再将该值转换回二进制格式以存储在 image 列中。相反，应用程序可以创建下列格式的存储过程：

CREATE PROCEDURE P(@p1 image) AS INSERT T VALUES (@p1)

当客户端应用程序请求执行过程 P 时，image 参数值将一直以二进制格式发送到服务器，从而节省处理时间并减少网络流量。

如果 SQL Server 存储过程中包含业务服务逻辑，因为业务服务逻辑将处理移动到数据，而不是将数据移动到处理，因而存储过程能提供更大的性能收益。

?1988-2000 Microsoft Corporation。保留所有权利。
应用程序设计
应用程序设计在决定使用 Microsoft? SQL Server? 2000 的系统的性能方面起关键作用。将客户端视为控制实体而非数据库服务器。客户端确定查询类型、何时提交查询以及如何处理查询结果。这反过来对服务器上的锁类型和持续时间、I/O 活动量以及处理 (CPU) 负荷等产生主要影响，并由此影响总体性能的优劣。

正因为如此，在应用程序的设计阶段做出正确决策十分重要。然而，即使在使用总控应用程序时（这种情况下似乎不可能更改客户端应用程序）出现性能问题，也不会改变影响性能的根本因素：客户端具有支配作用，如果不更改客户端则许多性能问题都无法解决。设计优秀的应用程序允许 SQL Server 支持成千上万的并发用户。反之，设计差的应用程序会防碍即使是最强大的服务器平台处理少数用户的请求。

客户端应用程序的设计准则包括：

消除过多的网络流量。
客户端和 SQL Server 之间的网络往返通常是数据库应用程序性能较差的首要原因，甚至超过了服务器和客户端之间传送的数据量这一因素的影响。网络往返描述在客户端应用程序和 SQL Server 之间为每个批处理和结果集发送的会话流量。通过使用存储过程，可以将网络往返减到最小。例如，如果应用程序根据从 SQL Server 收到的数据值采取不同的操作，只

要可能就应直接在存储过程中做出决定，从而消除过多的网络流量。

如果存储过程中有多个语句，则默认情况下，SQL Server 在每个语句完成时给客户端应用程序发送一条消息，详细说明每个语句所影响的行数。大多数应用程序不需要这些消息。如果确信应用程序不需要它们，可以禁用这些消息，以提高慢速网络的性能。请使用 SET NOCOUNT 会话设置为应用程序禁用这些消息。有关更多信息，请参见 SET NOCOUNT。

使用小结果集。
检索没必要大的结果集（如包含上千行）并在客户端浏览将增加 CPU 和网络 I/O 的负载，使应用程序的远程使用能力降低并限制多用户可伸缩性。最好将应用程序设计为提示用户输入足够的信息，以便查询提交后生成大小适中的结果集。有关更多信息，请参见使用高效数据检索优化应用程序性能。

可帮助实现上述目标的应用程序设计技术包括：在生成查询时对通配符进行控制，强制某些输入字段，不允许特殊查询，以及使用 TOP、PERCENT 或 SET ROWCOUNT 等 Transact-SQL 语句限制查询返回的行数。有关更多信息，请参见使用 TOP 和 PERCENT 限制结果集和 SET ROWCOUNT。

允许在用户需要重新控制应用程序时取消正在执行的查询。
应用程序决不应强迫用户重新启动客户机以取消查询。无视这一点将导致无法解决的性能问题。如果应用程序取消查询（例如使用开放式数据库连接 (ODBC) sqlcancel 函数取消查询），应对事务级别予以适当的考虑。例如，取消查询并不会提交或回滚用户定义的事务。取消查询后，所有在事务内获取的锁都将保留。因此，在取消查询后始终要提交或回滚事务。同样的情况也适用于可用于取消查询的 DB-Library 和其它应用程序接口 (API)。

始终实现查询或锁定超时。
不要让查询无限期运行。调用适当的 API 以设置查询超时。例如，使用 ODBC SQLSetStmtOption 函数。

有关设置查询超时的更多信息，请参见 ODBC API 文档。

有关设置锁定超时的更多信息，请参见自定义锁超时。

不要使用不允许显式控制发送到 SQL Server 的 SQL 语句的应用程序开发工具。
如果工具基于更高级的对象透明地生成 Transact-SQL 语句，而且不提供诸如查询取消、查询超时和完全事务控制等关键功能，则不要使用这类工具。如果应用程序生成透明的 SQL 语句，通常不可能维护好的性能或解决性能问题，因为在这种情况下不允许对事务和锁定问题进行显式控制，而这一点对性能状况至关重要。

不要将决策支持和联机事务处理 (OLTP) 查询混在一起。有关更多信息，请参见联机事务处理与决策支持。


只在必要时才使用游标。
游标是关系数

据库中的有用工具，但使用游标完成任务始终比使用面向集合的 SQL 语句花费多。

当使用面向集合的 SQL 语句时，客户端应用程序让服务器更新满足指定条件的记录集。服务器决定如何作为单个工作单元完成更新。当通过游标更新时，客户端应用程序要求服务器为每行维护行锁或版本信息，而这只是为了客户端在提取行后请求更新行。

而且，使用游标意味着服务器通常要在临时存储中维护客户端的状态信息，如用户在服务器上的当前行集。为众多客户端维护这类状态信息需消耗大量的服务器资源。对于关系数据库，更好的策略是让客户端应用程序快速进出，以便在各次调用之间不在服务器上维护客户端的状态信息。面向集合的 SQL 语句支持此策略。

然而，如果查询使用游标，请确定如果使用更高效的游标类型（如快速只进游标）或单个查询能否更高效地编写游标查询。有关更多信息，请参见使用高效数据检索优化应用程序性能。

使事务尽可能简短。有关更多信息，请参见事务和批处理对应用程序性能的影响。


使用存储过程。有关更多信息，请参见存储过程对应用程序性能的影响。


使用 Prepared Execution 来执行参数化 SQL 语句。有关更多信息，请参见 Prepared Execution (ODBC)。


始终处理完所有结果。
不要设计或使用在未取消查询时就停止处理结果行的应用程序。否则通常会导致阻塞和降低性能。有关更多信息，请参见了解和避免阻塞。

确保将应用程序设计为可避免死锁。有关更多信息，请参见将死锁减至最少。


确保已设置所有能够优化分布式查询性能的适当选项。有关更多信息，请参见优化分布式查询。

请参见