一、概述

“性能”这一术语有着几种不同的、差异微妙的含义。当人们谈到某个东西性能多少好时，他们想要表达的意思可能就是在一定的时间之内它完成了多少工作。例如，一个性能好的发动机运行起来更稳定，产生的动力更强大。对于开发小组，你同样也可能应用这个判断标准：一个性能好的开发小组工作时比较安静，而且能够生产出大量高质量的代码。对我来说，性能至少意味着两件事情——我的代码运行起来有多好，我的开发小组和我本人工作效率怎么样。无论哪一方面，本文介绍的技巧都将起到一定的帮助作用：帮助你更快地编写代码，帮助你编写更快的代码——安静地完成这一切，减少这样那样的错误。本文介绍的技巧主要面向ADO，特别是如何通过ADO访问SQL Server。但与此同时，我还将涉及一些适用范围更广的COM技巧，它们适用于你所编写的所有Visual Basic代码。

为了了解从哪些SQL Server数据访问代码编写技术、哪些体系、哪些开发习惯可以得到最好的性能，我已经花了不少时间。一些情况下，对于应用的整体性能来说，单一的技术意义很小，除非我们通过循环将性能的改善程度成倍放大。例如，在一个客户机/服务器应用中，当我们不是通过指定ODBC数据源（DSN）的方式连接数据库时，大约能够节省一到二秒的时间。对于应用整体的适用性或性能来说，这部分节省的时间所产生的影响很小。但是，如果我们在一个中间层组件上应用这种技术，这个组件每分钟（或每小时，每天）都要建立和关闭数据库连接数百（甚至数千）次，那么，这种技术将显着地影响系统的性能表现。因此，对于我在这里讨论的每一种技术，请务必考虑这个倍数因子——即，在一定的时间周期内，你的系统将执行同一段代码多少次。

当你开始寻求改进性能的方案时，请考虑一下你的应用（组件，或者是ASP代码）大部份的等待和处理时间花在什么地方。如果你发现应用程序把大量的时间花在等待Open或Execute方法执行完成，那么，你应该认真地检查一下服务器端的查询策略。包括ADO在内，所有的数据访问接口等待查询结果的时间都相同。例如，如果你有一个查询，SQL Server需要20秒才能完成它，不论用来执行该查询的是什么接口，没有一种接口能够比其他接口以更快的速度返回结果。虽然有些接口打开连接的速度比较快，有些接口处理结果集的速度比较快，但没有一种接口能够影响数据库引擎编译和执行查询的速度。因此，如果你的查询具有太高的“挑战性”——例如你没有对索引进行优化，你没有使用存储过程，服务器负载过重，或者你要求返回的记录数量太多——那么，世界上没有一种ADO技术能够帮助你提高性能。除非你解决了这些基本的查询问题，否则没有一种性能调整技术能够显着地改善整体性能。SQL Server的Query Analyzer是一个分析查询性能的优秀工具。它能够用图形的方式显示查询的执行过程，并对改进性能的方法提出建议。

如果你能够确信查询具有较高的效率，那么，你可以使用本文介绍的技术进一步调整ADO代码的性能。这里介绍的技巧将从各个方面帮助你简化和改进ADO编程，包括：建立和维护连接，构造和提交执行速度更快的查询，提高处理查询结果的效率，等等。

二、建立连接

在一个客户机/服务器应用中，我们可以用好几种方法把建立和初始化数据库连接所需要的时间隐藏起来，使得应用程序既能够打开连接，又不需要用户等待应用程序启动。首先，我们可以尝试异步连接。使用异步连接时，ADO启动连接操作之后，不等待连接完成就把控制权返回给应用程序——这样，应用程序就能够接着执行大部份初始化操作，以更快的速度完成form_load事件处理。如果关闭并重新建立连接的时间小于连接池释放连接的时间，那么这个连接实际上是即时的。但在许多情况下（特别是用户数量不多时），让连接保持打开状态更具有现实意义。在中间层组件或ASP页面内部，如果数据库查询多次重复出现，我建议你让Connection对象保持打开状态。

另外一个改进连接性能的办法是，避免使用带有DSN的ODBC。在Microsoft，ODBC已经转入了Quick Fix Engineering（QFE，快速修理工程）状态，它意味着：除非发现重大BUG，该公司将不再在OD