一、概述

　　 “性能”这一术语有着几种不同的、差异微妙的含义。当人们谈到某个东西性能多少好时，他们想要表达的意思可能就是在一定的时间之内它完成了多少工作。例如，一个性能好的发动机运行起来更稳定，产生的动力更强大。对于开发小组，你同样也可能应用这个判断标准：一个性能好的开发小组工作时比较安静，而且能够生产出大量高质量的代码。对我来说，性能至少意味着两件事情——我的代码运行起来有多好，我的开发小组和我本人工作效率怎么样。无论哪一方面，本文介绍的技巧都将起到一定的帮助作用：帮助你更快地编写代码，帮助你编写更快的代码——安静地完成这一切，减少这样那样的错误。本文介绍的技巧主要面向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，该公司将不再在ODBC或它的驱动程序上花时间。另外，考虑性能和部署问题时，ODBC DSN也是一个必须关注的问题。DSN必须安装到客户系统上，要求进行注册表查找，与OLE DB连接相比，它建立连接所需要的时间更长——特别是当你用直接编码的方式指定ConnectionString时，这一点尤其突出。从实际效果来看，避免使用DSN降低的系统开销很有限：如果完全取消连接建立过程，对于每个连接，你也许能够剩下二到五秒时间（假设数据库连接池中已经没有连接）。然而，如果你的应用程序需要频繁地建立连接，节省的时间累计起来就很可观了。

　　 建立数据库连接的时候，你要选择一个数据提供者。Microsoft建议我们使用OLE DB提供者替代默认的ODBC提供者。对比最新的OLE DB本地提供者和功能类似但较早的ODBC提供者，我感到前者令人不愉快的意外之事较少。但无论是哪种情况，你都应该在决定使用某个新的提供者之前对应用进行完整地测试——代码的性能、支持的功能、行为方式都有可能发生变化。

　　 在中间层和ASP中，在保持连接打开的情况下，我们不能（从实践来看）创建出可伸缩的组件——至少在多次调用之间是这样的。一般地，当IIS引用和释放组件、ASP页面的实例时，组件和ASP页面被频繁地装入、丢弃。由于基于ADO的代码每次执行时都必须建立、使用、释放数据库连接，最小化连接复杂程度的策略对性能的提高程度达到了可明显测量的程度。在这些情形下，对于我们连接数据库的速度来说，连接/会话池有着重要的意义。如果你为Command对象的ConnectionString属性指定合适的值（即，每次使用同样的服务器、初始目录、登录ID和其他参数），那么，连接已经打开且处于可用状态的机会很大。如果连接池中能够找到匹配的连接，连接（或重新连接）的时间将接近0（通常小于250 ms）。

　　 然而，如果ADO（或VB）代码不释放Connection对象，或者，我们在不同的实例之间改换了ConnectionString，OLE DB必须每次建立一个新的连接。如果出现了这种情况，我们将很快耗尽连接池内可用连接的数量。要确保连接被释放，我们必须在关闭连接之后把Connection对象设置为Nothing。另外，不要在Recordset Open方法中使用ConnectionString，而是以独立的方式打开Connection对象；这样，当我们要关闭Connection对象以及要把它设置成Nothing的时候，引用它就很方便了。

三、构造和提交查询

　　 在构造查询的时候，要搞清楚为什么必须这么做、为什么不能那么做是一个很复杂的问题。然而，一些基本的指导方针能够让构造高效查询的过程更加流畅、轻松。一般地，你不应该让查询浪费服务器时间。下面几个技巧能够帮助你构造出更好、更高效的查询。

　　 不要强制SQL Server每次执行查询的时候重新编译和构造查询执行计划。避免这种重复操作的一种简单方法是使用带有参数的存储过程。注意尽量不要使用ADO Command对象的Prepare属性——有时它不能正确工作。如果使用存储过程，你还可以通过消除不必要的“受影响行数”返回值进一步提高ADO性能——只需在存储过程中加入SET NOCOUNT ON就可以了。

　　 尽量减少与服务器的通信次数。如果你有几个相关的操作要执行，请把它们合并为一个存储过程，或者是一个可以在服务器上作为脚本执行的复合查询。避免使用方法（比如Refresh）和不适当的Parameters集合引用，它们会强制ADO增加额外的服务器通信过程。

　　 在客户机/服务器应用中，只构造Command对象一次，而不是每次使用Command对象的时候重新构造。你可以重新设置Command的参数值，然后在需要时执行它。

　　 当查询返回的不是一个记录集时，确保使用了adExecuteNoRecords选项，告诉ADO越过所有那些用来接收和构造记录集（Recordset格式）的代码。你可以把adExecuteNoRecords选项传递给Execute方法，或把它作为Command的选项。

　　 执行返回简单记录集的存储过程时，不要使用Command对象。所有的存储过程（以及Command对象）可以作为Connection对象的COM方法出现。让存储过程作为Connection对象的方法出现有着显著的性能优势，同时它也简化了代码。尽管这种技术对于那些有Return Status值或Output参数的存储过程没有什么帮助，但对于动作查询（INSERT、DELETE等）以及那些返回一个或多个记录的查询