优化是每个开发人员应该关心的问题。对于数据库访问，优化是一个关键问题。和其他任务相比，数据的访问显得相对慢些。
       因为数据访问的变化是如此之多，以致于几乎不可能提出一套固定的数据库操作的优化规则。通常碰到这类问题，经常得到这样的回答：“这取决于……”，因为这类优化问题取决于准备做什么。

9.3.1 常用的ADO技巧
       尽管优化取决于所执行的任务，但是仍然有一些常用的技巧：
       · 仅选择所需的列。当打开记录集时，不要自动地使用表名（即SELECT *），除非需要获得所有的列。使用单独的列意味着将减少发送到服务器或从服务器取出的数据的数量。即使需要使用全部列，单独地命名每个列也会获得最佳的性能，因为服务器不必再解释这些列是什么名字。
       · 尽可能使用存储过程。存储过程是预先编译的程序，含有一个已经准备好的执行计划，所以比SQL语句执行得更快。
       · 使用存储过程更改数据。这总是比在记录集上使用ADO方法执行速度快。
       · 除非必需否则不要创建记录集。运行操作查询时，要确定加入了adExecuteNoRecords选项，这样记录集就不会创建。当仅仅返回一个或两个字段的单行记录时（比如ID值），也可以在查询状态下使用这种方法。在这种情况下，存储过程和输出参数将会更快。
       · 使用适当的光标和锁定模式。如果所做的全部工作是从记录集中读取数据，并将其显示在屏幕上（比如，创建一个表），那么使用缺省的只能前移的、只读的记录集。ADO用来维护记录和锁定细节的工作越少，执行的性能就越高。

9.3.2 对象变量
       当遍历记录集时，一个保证能提高性能的方法是使用对象变量指向集合中的成员。例如，考虑下面的遍历含有Authors表的记录集的例子。
       While Not rsAuthors.EOF
              Response.Write rsAuthors("au_fname") & " " & _
                                    rsAuthors("au_lname") & "<BR>"
              rsAuthors.MoveNext
       Wend
       可以用下面的方法加速代码执行，同时使其更易于理解。
       Set FirstName = rsAuthors("au_fname")
       Set LastName = rsAuthors("au_lname")

       While Not rsAuthors.EOF
              Response.Write FirstName & " " & LastName & "<BR>"
              rsAuthors.MoveNext
       Wend
       这里使用了两个变量，并指向记录集的Fidds集合中的特定字段（记住，Fidds集合是缺省的集合）。因为这里建立了一个对象的引用，所以可以使用对象变量而不是实际的变量，这意味着脚本引擎的工作减少了，因为在集合中进行索引的次数变少了。

9.3.3 高速缓存大小
       高速缓存的大小是指ADO每次从数据存储中读取的记录的数量，缺省为1。这意味着当使用基于服务器的光标时，每当移动到另一条记录时，必须从数据存储中提取记录。举一个例子，如果增大高速缓存的大小为10，那么每次读ADO缓冲区的记录数将变为10。如果访问位于高速缓存内的记录，那么ADO不需要从数据存储中取记录。当访问位于高速缓存外的记录时则下一批记录将读入到高速缓存中。
       通过使用记录集的CacheSize属性，可以设置高速缓存的大小。
       rsAuthors.CacheSize = 10
       可以在记录集生命期的任何时候改变高速缓存的大小，但新的数量只在提取下一批记录后才有效。
       与许多改进性能的技巧类似，高速缓存没有通用的最佳大小，因为它随任务、数据和提供者的不同而改变。但是，从1开始增加高速缓存的大小总是能提高性能。
       如果你想看到这一点，可以使用SQL Server profiler并查看使用缺省的高速缓存打开一个记录集发生的情况，并比较增大高速缓存后发生的情况。增大高速缓存的大小不仅减低了ADO的工作量，同时也降低了SQL Server的工作量。

9.3.4 数据库设计
       不要希望只通过编程来提高对数据的访问效率，应该同时考虑一下数据库的设计。这里并不打算对数据库设计进行更多的讨论，但在使用Web站点数据库时应考虑以下几点：
       · 实时数据：向用户显示数据时，确保数据内容总是最新是十分重要的。以一份产品目录为例，目录内容改变的频率有多快？如果该目录并非经常改变，那么不必每次都从数据库中提取数据。每周一次，或在数据改变时从数据库产生一个静态的HTML页面应是一个更好的办法。
       · 索引：如果需要对表进行大量的查询，而不执行太多的添加数据操作，那么可以考虑为表建立索引。
       · 不规范化：如果站点有两个不同的目的（数据维护与数据分析），那么可以考虑采用一些不规范化的表以便有助于数据的分析。可以提供独立的、完全不规范化的但能正常更新的分析用表，为了改善性能甚至可以将这些分析表移到另一台机器上。
       · 数据库统计：如果使用的是SQL Server 6.x，如果数据被添加或删附除，那么应定期更新统计结果。这些统计结果用于产生一个查询计划，会影响查询的运行。请阅读SQL Books Online中的UPDATE STATISTIC以便了解更详细的内容。在SQL Server 7.0中这一任务自动完成。       这些都是十分基本的数据库设计技巧，但若只埋头于ASP代码可能不会考虑到这些。
9.3.5 数据高速缓存
   &nb