导读：对于一个应用程序的性能来说，其中数据库的性能是一个重要因素。由于应用程序及其相关的数据总会随着时间的推移而发生变化，因此必须不断地对数据库进行调优从而使其保持最佳水准。然而，花在调优上的努力应该在一个合理的范围之内。调优应该有一个度，超过了这个度的一切努力只能产生负面影响。如果应用程序的性能还不能令人满意，那么就应该考虑其他的变通办法，比如将该应用程序移到更快的平台上。下文就以讲解DB2数据库初始调优和设计方面为例为大家讲解数据库的调优。

　　本文中提到的命令和语法是基于 DB2 UDB V7 的，如果您使用的是 DB2 UDB V8，可能会稍有差异。

　　数据库设计方面的考虑

　　数据库调优始于设计阶段。假设硬件的选择是基于其他方面的考虑的，那么第一个要决定的就是存储架构。DB2 所使用的驱动器越多、越快，则潜在的性能将越好。对于表空间（tablespaces ）和其他对象（日志，备份文件，等等）的位置应该小心仔细地加以规划。尤其重要的是，要尽量保证日志和备份处在不同的驱动器上，这样做不但是为了性能，也是为了便于恢复。

　　表空间设计是整个数据库设计中的一个重要部分。通过创建不止一个的用户表空间可以增强性能。在下面三种情况下，使用多个表空间就很有用：

　　控制 I/O，如果这些表空间可以位于不同的驱动器上的话。

　　使用不同的页面大小（pagesize）。

　　控制缓冲池。

　　在大多数情况下，隔离的表空间是为索引和大型对象而创建的。以相同的页面大小创建多于一个的表空间并没有什么好处。

　　比起系统管理的表空间来，数据库管理（Database-managed）的表空间（尤其是在原始设备上）能够提供更好的性能。在决定页面大小时要记住，DB2 在一页上最多只能放 255 行，剩余的空间将不被使用。例如，如果平均行长度是 50 字节，那么一页最多使用的空间是 50*255=12750 字节。如果将该表放在页面大小为 16K 或者 32K 的表空间中，那么有些页就会被浪费。反之，如果有些表有更长的行，或者有很多的列，（具体的限制参见 SQL 参考手册中 CREATE TABLE 语句），那么页面大小就需要大于 4K。如果要以一种连续的方式（例如，群集表）来访问数据，那么采用更大的页面大小可以获得更好的性能，相反，如果对数据的访问采用的是随机方式，那么最好使用尽可能小的页面大小。

　　每个表空间都与具有相同页面大小的一个缓冲池相关联（一个缓冲池可以与不止一个的表空间相关联）。在使用多个缓冲池的时候要谨慎。由于可用的存储是有限的，为某个缓冲池分配过多的空间势必减少其他缓冲池的宽度，从而导致整体性能的降低。缓冲池调优最好是在检测数据库性能和基准的基础上进行。DB2 善于动态地管理可用空间，因此，在大多数情况下使用最少数量的缓冲池可以得到较好的性能。

　　长期以来，表设计的重要性就在于标准化。无冗余数据占据着最少的空间，并且具有最好的完整性。然而，无冗余数据并不能提供最好的性能。为了消除一点点的冗余，需要创建额外的表，这使得查询时需要额外地结合这额外创建的表，从而增加查询的复杂性。在平衡这两方面的需求时，需要有正确的判断。通常，通过生成冗余数据可以增加性能，但是这要采取一种受约束的方式，即冗余数据所采取的形式必须是索引和汇总表。如果要经常访问汇总数据，那么后者可以明显增加性能。对刷新频率的评估应该以信息需要保持的新鲜程度为依据。

　　索引是性能调优中最重要的方面之一。通常，对表的访问都是基于一些标准的。根据组成这些标准的一些列构建索引，可以动态地减少查询相关的开销。对于在线维护的不稳定的表应该创建少量的索引（一个或两个），而对于大型的历史性的表，由于需要通过多种方式进行查询，则需要创建很多的索引。一条索引中的列数应该尽量地少，除非很多查询都可以通过一个“index only”搜索来完成。为了这个目的， INCLUDE 选项允许将其他字段附加到索引上，其开销则小于完全索引方式。可以选择一个表的某一索引作为群集索引，或者在 REORGANIZE 命令中指定该索引。表数据将保持由该索引指定的顺序。当大量的查询基于该索引访问大量的行时，这种做法很有用。索引通常被放在它们自己的表空间中，拥有它们自己的缓冲池，以防止数据页数量很多时会将索引页挤出。