大型数据库系统设计与功效研究

摘要：影响数据库性能是综合性的。包括DBMS本身性能、数据库逻辑设计、数据库查询设计及数据库运行环境等。本文分析了数据库性能的影响因素并提出解决方案。从而有针对性解决数据库性能瓶颈因素。

关键词：数据库；索引；自定义函数；TPCC

中图分类号：TP311.131文献标识码：A文章编号：16727800（2011）012017003

作者简介：王乾坤（1972-）， 男， 江苏无锡人，硕士，无锡高等师范学校创意与软件系副教授，研究方向为计算机软件。

0引言

数据库特别是大型数据库的执行效率一直是困扰系统用户的最大问题。软件项目在设计时，由于测试用例的数据量很小，很多有关执行效率的问题都反映不出来。但当项目交付使用并运行一段时间后，随数据量增大执行效率将成为突出问题。开发者可能由于服务期已过，也没有精力和兴趣去解决这个“软”性的性能问题。同时执行效率和数据库系统的硬件参数配置和网络参数配置有很大关系，逻辑设计和各种数据库工具的使用将对数据库执行效率将带来确定性的影响。数据库项目设计技巧也会使系统有效避开数据流峰值和瓶颈等不利因素。

本文将对从数据库选型、数据库系统硬件配置、数据库系统结构设计对执行效率的综合影响及相应的量化方式进行研究和分析。

1数据库选型

面对品种繁多的数据库产品，如何才能独具慧眼，选中适合自己的数据库产品呢？正确的评估、选型与数据库技术本身同样重要。通常数据库厂商都会在性能清单和技术基准表中尽量展现产品最佳的一面，对产品弱点却避免提及或进行遮掩。其实在挑选和评估过程中，首要目标是选择一款能够满足甚至超过预定要求的技术或解决方案。选型的正确方法将使用户在面对众多产品时，做出最佳选择。数据库选型必须考虑五大因素：开发要求 、性能/成本、数据库运行和管理、可升级性和总体拥有成本。

首先，需要清楚自己究竟想使用什么开发技术。例如，你是要以访问传统的关系型数据库？还是要以纯面向对象技术构建J2EE应用平台？又或是需要建设XML Web Services？如果你要实现的是纯关系型的开发典范，那么实际要使用的受支持的标准（和非标准）SQL功能有多少？如果你要规划的是面向对象开发策略，那么在原计划里的数据库支持真正的面向对象吗？它是如何支持的？若有需要,它能同时提供SQL的功能吗？数据库支持这个功能吗？虽然,有些关系型数据库声称支持对象开发，但实际上并不是直接支持的。这种非直接的体系结构将导致更多的事务处理故障，以及潜在的可升级性和性能问题。

另外，你还需要确定自己的前端技术如何与后端进行“对话”。你的业务逻辑是放在客户机一端呢？还是放在服务器一端？你要使用哪些脚本语言？它们与后端服务器的兼容性如何？它们是快速应用开发（RAD）环境吗？

目前，实现基于关系型数据库的应用可以选择传统的主流品牌，这些数据库产品有着很成熟的关系技术以及广泛的应用资源。但是,如果实现的是基于面向对象技术的应用、又或是数据结构更为复杂时，不妨考虑目前一些公司推出的所谓后关系数据库。它所代表的正好是关系数据库和面向对象技术的融合，以多维数据引擎作为核心，从根本上支持复杂的对象存储及主流的二维表，同时也已经配备了功能强大的应用服务引擎，可作对象逻辑操作的平台。它的出现已经为传统数据库领域带来了冲击，而在面向对象数据库方面更是广受欢迎。

测量数据库性能最常见的方法是TPC基准。TPC明确地定义了数据库方案、数据量以及SQL查询。测量的结果是，在特定的操作系统上配置了特定的数据库版本，以及在惊人的硬件条件下每项事务的成本是多少――其中的事务可以是TPC测试中定义的任何数据库操作。

从理论上来讲，这类基准旨在提供不同产品间客观的比较值。但在现实中，这些方案又有多少能准确反映并回答你在挑选技术时所存在的疑惑？其次，所有技术厂商的TPC基准都会超过以前的结果。这样，TPC基准在更大程度上反映的是为解决问题而投入的内存和CPU量，而不是数据库性能的任何真实表现。只有在真实的环境中进行实际的比较测试才可以推断出数据库的预期性能及评估所需成本。常用的方法包括平衡移植，把原来的数据转移到类似硬件上的另一套数据库，然后以真实的客户端连接这套测试对象。又或是以数据产生针对真实的数据模型，建立出庞大的数据量，再以客户端连接作测试。

这种做法跟实验室中的做法的不同之处有以下几点：第一，试验中的硬件构架跟你预期的方案不会有太大的差别；第二，所测试的事务在宽度和深度方面跟未来计划的也差不太远；第三，如果是硬件条件一样，我们可以直接看出测试对象跟原来方案有着多少差异。

掌握了以上结论之后，我们应该可以更精明地为所需的性能投入相应的成本。换句话说，我们将能够更准确地预测各种数据库的性能与相应的成本。

2数据库设计

2.1数据模式设计

在数据库逻辑设计过程中，为了保证数据库的一致性和完整性，数据库要按照关系数据库的规范化要求设计。满足这些范式条件的关系模式可在不同程度上避免冗余、插入和更新异常问题。在基于表驱动的系统中,基本表的设计规范是第三范式3NF。但是在实际工作中,对于经常需要执行查询、汇总的列,如果按规范化理论设计肯定会增加表的连接操作而降低系统性能,这时可以降低数据库对规范化理论的要求，以便满足实际应用操作的需要。所以合理使用冗余会为查询带来很大的好处，比如经常被查询的汇总数据可以在平时工作中就累加好，不需要到查询时再使用如sum之类的函数。

2.2索引设计

索引即将表数据按索引要求而产生有序的数据副本，这样的查询可以在有序表中进行，提高查询数据的速度, 改善系统性能。可是使用索引也会耗费磁盘空间, 增加开销, 降低DML (INSERT、UPDATE、DELETE )操作执行的效率。因此设计时应尽量选择有用的索引,在提高查询速度和节省存储空间之间寻求最佳的平衡点。

数据库服务器对数据进行访问一般采用下面的两种方式：索引扫描：通过索引访问数据；表扫描：读表中的所有页。当对一个表进行查询时，如果返回的行数占全表总行数的10%到15%时，使用索引可以极大的优化查询的性能。但是如果查询涉及到全表40%以上的行时，表扫描的效率比使用索引扫描的效率高。在具体使用的过程中，要结合实际的数据库和用户的需求来确定要不要索引以及在什么字段上建立什么样的索引。下面给出一些通用的规则：

①在经常用作过滤器或者查询频率较高字段上建立索引；②在SQL语句中经常进行GROUP BY、ORDER BY的字段上建立索引；③在不同值较少的字段上不必要建立索引，如性别字段；④对于经常存取的列应避免建立索引；⑤用于联接的列（主健/外健）建立索引；⑥在经常存取的多个列上建立联合索引，但要注意联合索引的建立顺序要按照使用的频度来确定。

聚集索引是指行的物理顺序与行的索引顺序相同的索引。一个表只能有一个聚集索引。非聚集索引是指定表的逻辑顺序索引，行的物理顺序与索引顺序不尽相同，每个表可以有多个非聚集索引。缺省情况下建立的是非聚集索引，但是在一些特定的情况下建立非聚集索引会极大的缩短查询的时间。有大量重复值、且经常有范围查询（between，>，=，

使用聚集索引的最大好处就是能够根据查询要求，迅速缩小查询范围，避免全表扫描。比如要返回2009年10月1日到2010年10月1日之间的数据，如果在日期的字段建立了聚集索引，那么数据本来就是按照日期的顺序排列的，只要找到开始和结尾日期的数据就可以了，可以极大的节省时间。而如果使用非聚集索引，必须查到这个时间段中每个日期对应的位置，然后在根据位置存取数据，明显效率很低。显而易见，使用聚集索引的优势很明显。一个表只能按照一个固定的顺序来存储数据。因此，在建立聚集索引的时候一定要和实际查询相结合，看哪个字段对于查询贡献大，而且操作不是很频繁。

索引有助于提高检索性能，但过多或不当的索引也会导致系统低效。因为用户在表中每添加一个索引，数据库就要做更多的工作。过多的索引甚至会导致索引碎片。所以说，我们要合理使用索引体系，特别是对索引的创建，更应精益求精，使数据库的性能得到更好的发挥。

创建索引可以根据查询业务的不同分为两种:单一列索引和联合索引。单一列索引就是指在表的某一列上创建索引，联合索引是在多个列上联合创建索引。两种索引比较结果如下：

①索引所占用空间:单一列索引相对要小；②索引创建时间:单一列索引相对短；③索引对insert，update，delete的影响程序:单一列索引要相对低；④在多条件查询时，联合索引效率要高。

索引的使用范围:单一列索引可以出现在where 条件中的任何位置，而联合索引需要按一定的顺序来写。最后要注意，对数据量大及使用频繁的数据库需要是要用索引优化器来优化索引。

2.3查询设计

从大多数系统的应用实例来看, 查询操作在各种数据库操作中所占据的比重最大。许多程序员在开发数据库应用程序时,只注重用户界面的华丽,并不重视查询语句的效率问题,导致所开发出来的应用系统效率低下。因此,如何设计高效合理的查询语句就显得非常重要。

(1)正确地使用索引

正确使用索引可以大大提高查询效率, 在条件子句中应尽量考虑有用索引的使用。例如,在学生登记表中,如果创建学号为单列索引, 那么查询语句的WHERE 子句中应使用学号这个索引,使之成为有用索引。

(2)模糊匹配的避免

LIKE关键字支持通配符匹配，技术上称为正则表达式。但这种匹配特别耗费时间，尽量避免使用模糊匹配。

(3)子查询合并

子查询合并是将某些特定的子查询重写为等价的多个表的连接操作。子查询合并的作用在于能使查询语句的层次尽可能地减少,从而可提高查询的效率。子查询合并的一般规则为:①如果外层查询的结果没有重复,即SELECT子句中包含主码,则可以合并其子查询,并且合并后的SELECT 子句前应加上DISTINCT 标志；②如果外层查询的SELECT 子句中有DISTINCT标志,那么可以直接进行子查询合并；③如果内部子查询结果没有重复元组,则可以合并。

(4)使用临时表优化查询

在涉及相关查询的某些情形中， 构造临时关系可以提高查询效率。

3数据库系统配置

3.1硬件系统配置

数据库服务器中最重要的配置参数有内存、CPU和网卡。目前影响最大的是内存。尽可能把数据放入内存，比临时从硬盘中调入内存来的要快的多。如果内存太小，小会造成数据在内存与硬盘之间的频繁调入调出，如果内存的占用率超过50%,那就要考虑是否要扩大它。在内存足够大时，系统可以考虑在每天的初始运行时，将数据预装入内存也是一种行之有效的好方法。

3.2功能模块配置

系统无论是C/S架构还是B/S架构。数据信息的系统处理时间都是由三部分组成：数据库服务器处理时间；网络传输时间；客户端处理时间。所以解决系统性能的关键点就在于如何使得这三个时间的总和最小。

在系统中数据库服务器的配置和性能往往是最高。但它的工作也最繁重，要同时应对若干用户的操作请求。同时我们注意到有些系统工作可以放在客户端处理，也可以由数据库服务器处理，但怎样安排才好呢？这要具体看系统各组成部分的性能。

(1)如客户端功能弱而数据库服务器能力强，那么有些问题就可以用触发器、自定义函数和视图等形式交给数据库服务器去处理。这样不仅可以减轻客户端压力还带来系统可维护性好的益处。

(2)反之，如客户端处理能力较强，而数据库服务器压力过大的话，有些诸如触发器要完成的工作可以有客户端来完成，如数据验证、自动编号生成、数据统计等这样一些工作可以交与客户端来完成。

(3)充分兼顾网络传输时间。目前的网络特别是互联网络，其流量压力越来越大,峰值越来越频繁。为平衡客户端与数据库服务器的工作，有时会将一些半加工的数据在网络上传输，这些数据往往数据量就很大，给网络环节带来压力就大。如果只能传输处理结果而不传输中间数据，这样数据传输时间就最少，但这样平衡客户端和数据库服务器的工作又比较难。所以要具体情况具体分析，充分兼顾网络传输时间对系统的影响。

4数据库性能测试

目前常用的数据库基准性能测试工具是TPCC。关于它的运用方法这里不再赘述。当系统的性能下降以后，我们要分析下降的现象及产生原因。常见的有：①原本好好的，突然变得很慢；②工作高峰时比较慢；③有的客户端慢；④渐渐变慢。

这里我们可以通过计算机性能检测工具来观察计算机性能如CPU和内存的使用率，从而判断是硬件还是系统设计的原因，并针对性提出解决方案。

参考文献：

[1][韩]李华植.海量数据库解决方案[M].北京:电子工业出版社,2011.

[2]牛新庄.BD2数据库性能调整和优化[M].北京:清华大学出版社,2009.

[3][美]荫蒙.数据仓库[M].北京:机械工业出版社,2004.

[4]白鳝.Oracle优化日记：一个金牌DBA的故事[M].北京:人民邮电出版社,2010.（责任编辑：余晓）