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

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 数据高速缓存
       首先需要注意的是，数据高速缓存与记录集高速缓存虽然都用于改善性能，但两者是无关的。数据高速缓存是临时的数据存储区，允许使用高速缓存中的数据，而不是重新生成新的数据。这只适用于那些不经常改动但多次被访问的数据。
       在ASP中一个最简单的缓存数据的方法是使用Application和Session范围的变量。例如，假设有一些需要选择书类型的网页。正常情况下，可能会创建一个含有以下函数的包含文件。
<%
Function BookTypes()

  Dim rsBookTypes
  Dim strQuote

  strQuote = Chr(34)

  Set rsBookTypes = Server.CreateObject ("ADODB.Recordset")

  ' Get the book types
  rsBookTypes.Open "usp_BookTypes", strConn

  Response.Write "<SELECT NAME=" & strQuote & lstBookType & strQuote & ">"
  While Not rsBookTypes.EOF
    Response.Write & "<OPTION>" & rsBookTypes("Type") & "</OPTION>"
    rsBookTypes.MoveNext
  Wend
  Response.Write & "</SELECT>"

  rsBookTypes.Close
  Set rsBookTypes = Nothing

End Function
%>
这仅仅是调用一个存储过程，从而得到书的类型，同时创建一个SELECT列表。上述代码的缺点在于每次调用该函数都必须访问数据库。因此，重新修改这个函数。
<%
Function BookTypes()

  Dim rsBookTypes
  Dim strQuote
  Dim strList

  ' See if the list is in the cache
  strList = Application("BookTypes")
  If strList = "" Then
    ' Not cached, so build up list and cache it
    strQuote = Chr(34)

    Set rsBookTypes = Server.CreateObject ("ADODB.Recordset")

    ' Get the book types
    rsBookTypes.Open "usp_BookTypes", strConn

    strList = "<SELECT NAME=" & strQuote & lstBookType & strQuote & ">"
    While Not rsBookTypes.EOF
      strList = strList & "<OPTION>" & rsBookTypes("type") & "</OPTION>"
      rsBookTypes.MoveNext
    Wend
    strList = strList & "</SELECT>"

    rsBookTypes.Close
    Set rsBookTypes = Nothing

    ' Check the list
    Application("BookTypes") = strList
  End If

  BookTypes = strList

End Function
%>
这段代码不只是打开记录集，它检查Application变量BookType的值是否为空。如果不为空，则使用该变量的内容。如果为空，则像以前一样打开记录集。显然，一旦第一个人运行了这一例程，便缓存了数据，因此这只对那些不常变化的数据是有用的。
如果想在用户基础上缓存数据，可以使用Session范围的变量，但这里必须注意Session存在有效期。过期后会话层变量将和会话一起取消，代码便有可能终止运行。
利用Web Application Stress（WAS）工具，得到了表9-4的分析结果：
表9-4  利用WAS工具得到的分析结果

很明显性能有所改善。但不要采用上述方法缓存一切内容。毕竟，这种方法只适用于那些已经格式化后用于显示的数据。除此之外，还要考虑到如果Web服务器只为特定的一个人服务，那几乎不是一个典型的Web服务器的用法。使用WAS可以在一个服务器上模拟多个用户，这样可以更实际地测试应用程序。
通过模拟一定数量的用户，Web Application Stress工具可以对Web页面进行承受力测试。该工具有一个简单的图形界面，使用起来非常容易。可以从http://homer.rte.microsoft.com/获得更多的信息，也可以下载该工具。
高速缓存对象
若要缓存未格式化过的数据该怎么办？可以在不同地方以不同的方式使用吗？当然，也可以用Application或Session变量这样做。考虑一下书标题的情况。你或许希望在多个页面中使用这个标题，也许在一个表格中显示所有的标题，或在一个列表框中显示供用户选择等等。你可能会想到可以缓存记录集本身而无需缓存含有标签的HTML文本。
可以在Application或Session变量中缓存对象，但有两个主要的问题需要注意：
· 存放在Application变量中的对象必须支持自由线程，因此必须是自由线程对象或双线程对象。这意味着无法在Application变量中缓存由VB创建的组件。
· 在Session状态中存放单元线程对象意味着创建该对象的线程是唯一允许访问它的线程。因此IIS无法较好地完成线程管理，因为任何试图访问这个对象的页面都必须等待原有线程服务于该页面。这将扼杀扩展应用程序的任何机会。
对于线程问题的讨论参见第15章。
默认情况下，ADO作为单元线程对象装载，这主要是因为部分OLE DB提供者并非是线程安全的。在ADO安装目录中有一个注册表文件，可将ADO转换成双线程模型，由此使ADO对象可以安全地存放在Application和Session对象中。
你也许会认为所有的问题都解决了，可以通过使用各种类型的对象获得显著的速度提升，但这并不一定。许多人已经认识到既然连接到数据库是一个相对昂贵的操作，那么缓存Connection对象可在再次连接时节省大量的时间。的确如此，但缓存Connection对象意味着该连接永远不会关闭，因此连接缓存池的工作效率比较低。连接缓存池隐含的一个思想实际上是减少服务器上使用的资源，而缓存ASP状态中的对象显然不能减少资源的使用。事实上还增加了对它们的占用，因为每缓存一个对象便要占用服务器的资源，对于一个繁忙的站点而言，这将极大地降低Web服务器的效率。
所以不应存储Connection对象，但对于Recordset对象，特别是断开连接的记录集呢？假定ADO已从单元线程变成了双线程，就没有什么理由不这么做了，只要确切知道自己在做什么。不要认为这会自动地改善ASP页的性能。每一个缓存的记录集都在内存和ASP管理方面占用服务器的资源，因此不要缓存大的记录集。
另一个技巧是使用记录集的GetRows方法，将记录集转换成一个数组。因为数组并不像Recordset对象那样受线程问题的影响，因此非常适合用于会话层的变量。然而它同样也占用服务器资源，还必须考虑处理数组的时间。
构建自己的应用程序，缓存技巧并非是必要的。