Ch2.2-数据库开发技术

1、专题2：数据库开发技术l数据库项目的开发是一个复杂的工程，不同的数据结构设计和查询策略可能带来极大的性能差异，一个好的数据库产品不等于就有一个好的应用系统，如果不能设计一个合理的数据库模型，不仅会增加客户端和服务器段程序的编程和维护的难度，而且将会影响系统实际运行的性能。l一般来讲，在一个MIS系统分析、设计、测试和试运行阶段，因为数据量较小，设计人员和测试人员往往只注意到功能的实现，而很难注意到性能的薄弱之处，等到系统投入实际运行一段时间后，才发现系统的性能在降低。l因此，数据库的设计并不是一件简单的事情，从逻辑设计到物理设计是一个技术门槛。这里从几个方面分析数据库开发中的性能问题，其中有些

2、是通用的，有些则与具体的数据库实现如Oracle、MSSQLServer或DB2相关，但总体上这里尽可能描述一些通用的原理。l一、数据库设计的基本过程l二、数据库设计的基本策略l三、数据库应用的物理设计l四、客户端优化l五、数据库应用性能调优一、数据库设计的基本过程l数据库设计是建立数据库及其应用系统的核心和基础，它要求对于指定的应用环境，构造出较优的数据库模式，建立起数据库应用系统，并使系统能有效地存储数据，满足用户的各种应用需求。按照一般规范化的设计方法，常将数据库设计主要分为两个阶段：逻辑设计物理设计数据库逻辑设计l确定系统的名称、范围、目标功能和性能、所需的资源，对分布式数据库系统，还

3、应分析用户环境及网络条件，以选择和建立系统的网络结构。l在用户调查的基础上，通过分析，逐步明确用户对系统的需求，包括数据需求和围绕这些数据的业务处理需求。通过对组织、部门、企业等进行详细调查，在了解现行系统的概况、确定新系统功能的过程中，收集支持系统目标的基础数据及其处理方法如实时处理、批处理等。然后产生反映企业各组织信息需求的数据库概念结构，即概念模型。l概念模型必须具备丰富的语义表达能力、易于交流和理解、易于变动、易于向各种数据模型转换、易于从概念模型导出与DBMS有关的逻辑模型等特点。最后将ER图的实体和联系类型，转换成选定的DBMS支持的数据类型。数据库物理设计l物理设计的主要任务是对

4、数据库中数据在物理设备上的存放结构和存取方法进行设计。数据库物理结构依赖于给定的计算机系统，而且与具体选用的DBMS密切相关。l物理设计常常包括某些操作约束，如响应时间与存储要求等。l完成物理设计后，还需要进行数据库设计的实施，主要分为建立实际的数据库结构；装入试验数据对应用程序进行测试；装入实际数据建立实际数据库l三个步骤。二、数据库设计的基本策略l在计算机硬件配置和网络设计确定的情况下，影响到应用系统性能的因素不外乎为数据库性能和客户端程序设计。l大多数数据库设计员首先进行逻辑设计，而后进行物理设计。数据库逻辑设计去除了所有冗余数据，提高了数据吞吐速度，保证了数据的完整性，清楚地表达数据元

5、素之间的关系。而对于多表之间的关联查询（尤其是大数据表）时，其性能将会降低，同时也提高了客户端程序的编程难度。l此外，除了业务逻辑的设计，在数据库的设计过程中还包括一些其他设计，如数据库的安全性、完整性、一致性和可恢复性等方面的设计，但这些设计总是以牺牲效率为代价的，设计人员的任务就是要在效率和功能之间进行合理的权衡。因此，物理设计需折衷考虑，根据业务规则，确定对关联表的数据量大小、数据项的访问频度，对此类数据表频繁的关联查询应适当提高数据冗余设计。l此外，不同的DBMS在具体的功能上可能会有不同的实现方法和优法策略，我们可以看到不同的数据库设计策略在数据完整性、时间与空间等方面会有明显的差异

6、。因此不可能有完全通用的数据库设计策略。l逻辑设计：复习？ 用E-R图画出学生、课程、成绩、老师之间的逻辑关系，并用关系范式加以说明。三、数据库应用的物理设计l1、完整性、规范化、规则和约束l2、数据可迁移性l3、数据库性能调优1、完整性、规范化、规则和约束l逻辑设计的目标与结果：第三范式 在逻辑设计上为了减少数据冗余，保证数据库的一致性和完整性，数据建模时一般都需要规格化达到第三范式，如果需要冗余也是因为外键关系和数据引用完整性的需要。为此，设计人员往往会设计大量的的表间关联来尽可能降低数据冗余。回顾：l第1范式：没有重复的组或多值的列。l第2范式：每个非关键字段不能依赖于一个组合关键字的部

7、分（部分依赖）。l第3范式：一个非关键字段不能依赖于另一个非关键字段（依赖传递）。结果：l遵守这些规则的数据库设计会产生较少的列和更多的表，因而也就减少了数据冗余，也减少了用于存储数据的页。l但是，表间关联是一种强制性措施，建立后，对父表和子表的插入、更新、删除操作均要占用系统的开销。回顾：l数据完整性的保持：使用规则（Rule）和约束（Check）来防止系统操作人员误输入造成数据的错误是设计人员的另一种常用手段。结果：l但是，不必要的规则和约束也会占用系统的不必要开销（需要注意的是，约束对数据的有效性验证一般要比规则快）。解决方案：l反规范化的考虑 逻辑数据模型是数据的理想蓝图，物理数据模型

8、才是对数据的现实的实现。规范化只关注数据的意义，而没有考虑对于访问数据的应用程序的性能需求。完全规范化的数据库设计在性能方面要受到质疑。 适当的非规格化虽然需要占用更多的空间，但通过减少频繁的连接、聚集和推导可以提高数据查询的性能。l例子：l性能问题的最常见的例子是连接（JOIN）操作。通常，规范化过程最终将相关的信息放入不同的表中。于是应用程序需要从多个这样的表中访问数据。关系数据库为SQL语句提供了从一个以上的表中访问信息的能力，这是通过连接多个表来完成的。连接操作可能要消耗大量的资源和时间，这取决于表的数量以及这些表各自的长度。例如，客户经理号与客户经理名，客户经理名依赖客户经理号，如果

9、在客户经理业绩表中仅有客户经理号，在查询客户经理业绩时就需要做表的关联，从而降低查询响应速度。非规格化以数据更新和数据空间的损失为代价换取数据访问的优化。一般的非规范化形式有：列复制，创建数据阵列，预连接表，预聚集数据。l因此设计人员在设计阶段应根据系统操作的类型、频度加以均衡考虑。对于具有经常被请求的列的多个表，一种是复制其中的数据，一种是执行表连接，两者谁的成本更高呢？在逻辑数据库设计过程中，您可以毫无保留地规范化数据模型，然后再加入一定程度的反规范化，作为潜在的性能调优的一种选择。l如果确实打算反规范化，那么一定要为此制作完整文档：较详细地描述您所采取的反规范化步骤背后的原因。2、数据可

10、迁移性l命名规范 不同的数据库产品对对象的命名有不同的要求，因此，数据库中的各种对象的命名、后台程序的代码编写应采用大小写敏感的形式，各种对象命名长度不要超过30个字符，这样便于应用系统适应不同的数据库。lIDENTIFY/AUTO INCREASE/SEQUENCE字段 如果需要数据迁移，使用IDENTIFY/AUTO INCREASE/SEQUENCE字段作为表的主键与其它表关联可能会造成问题，必须事先考虑好可行的方案。有时，GUID类型要比自动递增字段更适合数据迁移。3、数据库性能调优l数据类型l索引l硬件、I/O效率配置数据类型数据类型的合理选择对于数据库的性能和操作具有很大的影响。Q

11、1: 字符型-定长与不定长记录，如何选择？固定长度的记录要优于可变长度的记录。在DB2中专门为处理固定长度的记录进行优化。如果记录是固定长度的，那么就无需将其从存储它的初始页面转移到其他地方。而对于可变长度的记录，其长度可能会变得不再适合初始页，因此必须将其转移到其他页。之后，每当需要访问该记录时，就必须发生额外的页引用。因此，在CHAR和VARCHAR类型的选择上，需要考虑到这一点，对少于或等于30个字节的字段，应避免使用VARCHAR类型，因为不但不能节约空间，还可能造成浪费。 然而，在用类似like %a%查询时，查询耗时和字段值总长度成正比，所以CHAR类型的效率要低于VARCHAR类

12、型。当然，此类查询本身也是应该尽力避免，或是用全文索引来解决。Q2:数字代码用哪种类型？ 整数是最常用的数据类型，理论上计算机处理整数的效率是最快的，要比处理字符串快2N倍，其中N是字符串中字符的个数。所以，在设计表结构时，一些计算时频繁用到的字段，如分支机构代码、系统用户代码、客户代码等，应尽量采用整数类型。 另一方面，从I/O的角度，与每个表列相关的数据类型应该反映数据所需的最小存储空间，特别是对于被索引的列更是如此。比如能使用smallint类型就不要用integer类型，这样索引字段可以被更快地读取，而且可以在一个数据页上放置更多的数据行，因而也就减少了I/O操作。这又需要一个折衷。Q

13、3:日期型数据的优劣？优点是有众多的日期函数支持，因此，在日期的大小比较、加减操作上非常简单。但是，在按照日期作为条件的查询操作一般也要用函数，相比其它数据类型速度上就慢许多，因为用函数作为查询的条件时，服务器无法用先进的性能策略来优化查询而只能进行表扫描遍历每行。Q4:个人简介等短文本的存储用Text或Blob类型是否合适？ 属于指针型数据，主要用来存放二进制大型对象（BLOB）。这类数据的操作相比其它数据类型较慢，因此要避开使用。索引l索引是数据库中重要的数据结构，它的根本目的就是提高查询效率。建索引是提高数据访问效率的重要途径，l但建索引有时并不一定能起到作用，索引不能满足未知需求，有时

14、会适得其反，降低系统性能。l建立必要的索引，这就是数据库性能优化的关键。这一点看似容易实际却很难。难就难在如何判断哪些索引是必要的，哪些又是不必要的。判断标准：看这些索引是否对我们的数据库性能有所帮助。l具体到方法上，就必须熟悉数据库应用程序中的所有SQL语句，从中统计出常用的可能对性能有影响的部分SQL，分析、归纳出作为Where条件子句的字段及其组合方式；在这一基础上可以初步判断出哪些表的哪些字段应该建立索引。l其次，必须熟悉应用程序。必须了解哪些表是数据操作频繁的表；哪些表经常与其他表进行连接；哪些表中的数据量可能很大；对于数据量大的表，其中各个字段的数据分布情况如何；等等。对于满足以上

15、条件的这些表，必须重点关注，因为在这些表上的索引，将对SQL语句的性能产生举足轻重的影响。一些索引设计原则：l表的主键、外键必须有索引；l正确的选择数据类型；l数据量超过300的表应该有索引（例外：见下一条）；l索引应该建在选择性高的字段上。如果索引的惟一值有限（如100），则不宜使用索引（特例见下页）。l经常与其他表进行连接的表，在连接字段上应该建立索引，即使没有外键；l经常出现在ORDER BY、GROUP BY、WHERE子句中的字段，特别是大表的字段，应该建立索引；l索引应该建在小字段上，对于大的文本字段甚至超长字段，不要建索引；l频繁进行数据操作的表，不要建立太多的索引；l在最恰当的

16、列上建立聚集索引； 索引的选择性低，但数据的值分布差异很大时，仍然可以利用索引提高效率。如在数据分布不均匀的特殊情况下，选择性不高的索引也要创建。如表ServiceInfo中数据量很大，假设有一百万行，其中有一个字段DisposalCourseFlag，取值范围为枚举值：0，1，2，3，4，5，6，7。按照前面说的索引建立的规则，“选择性不高的字段不应该建立索引，该字段只有8种取值，索引值的重复率很高，索引选择性明显很低，因此不建索引。然而，由于该字段上数据值的分布情况非常特殊，具体如下表。而且，常用的查询中，查询DisposalCourseFlag6 的情况既多又频繁，毫无疑问，如果能够建立

17、索引，并且被应用，那么将大大提高这种情况的查询效率。因此，我们需要在该字段上建立索引。取值范围取值范围1567占总数据量的百分比1%98%1%l复合索引需要进行仔细分析；尽量考虑用单字段索引代替，如必须，则考虑：l正确选择复合索引中的主列字段，一般是选择性较好的字段，哪一列唯一数据值较少，哪一列就应该为第一个索引，这样可以确保数据可以通过索引进一步交叉排序。将查询中引用最多的列放在定义的前面。例：在SQL SERVER中使用查询分析器分析查询条件分别为第一索引字段和第二索引字段的查询，看其全表扫描情况。l复合索引的几个字段是否经常同时以AND方式出现在Where子句中？单字段查询是否极少甚至没

18、有？如果是，则可以建立复合索引；否则考虑单字段索引；如果复合索引中包含的字段经常单独出现在Where子句中，则分解为多个单字段索引；l如果复合索引所包含的字段超过3个，那么仔细考虑其必要性，考虑减少复合的字段，更要避免在索引中使用多于个的列，避免覆盖多个查询的大型索引。在聚集索引中用到的列越多，在非聚集索引中包含的聚集索引参考位置就越多，需要存储的数据也就越多。这样将增加包含索引的数据表的大小，并且将增加基于索引的搜索时间；l如果既有单字段索引，又有这几个字段上的复合索引，一般可以删除复合索引；硬件、I/O效率l硬件-操作系统性能的好坏直接影响数据库的使用性能，如果操作系统存在问题，如CPU过

19、载、过度内存交换、磁盘I/O瓶颈等，在这种情况下，单纯进行数据库内部性能调整是不会改善系统性能的。l可以通过系统监视器(System Monitor)来监控各种设备，发现性能瓶颈。l一种常见的硬件性能问题就是缺乏处理能力。系统的处理能力是由系统的CPU数量、类型和速度决定的。如果系统没有足够的CPU处理能力，它就不能足够快地处理事务以满足需要。我们可以使用System Monitor确定CPU的使用率，如果以75%或更高的速率长时间运行，就可能碰到了CPU瓶颈问题，这时应该升级CPU。l但是升级前必须监视系统的其他特性，如果是因为SQL语句效率非常低，优化语句就有助于解决较低的CPU利用率。而

20、当确定需要更强的处理能力，可以添加CPU或者用更快的CPU替换。l内存量也是DBMS性能最关键因素之一。而内存同I/O子系统的关系也是一个非常重要的因素。例如，在I/O操作频繁的系统中，DBMS用来缓存数据的可用内存越多，必须执行的物理I/O也就越少。这是因为数据将从数据缓存中读取而不是从磁盘读取。同样，内存量的不足会引起明显的磁盘读写瓶颈，因为系统缓存能力不足会引起更多的物理磁盘I/O。可以利用System Monitor检查Buffer Cache Hit Ratio计数器，如果命中率经常低于90%，就应该添加更多的内存。l由I/O子系统发生的瓶颈问题是数据库系统可能遇到的最常见的同硬件有

21、关的问题。配置很差的I/O子系统引起性能问题的严重程度仅次于编写很差的SQL语句。lI/O子系统问题是这样产生的：一个磁盘驱动器能够执行的I/O操作是有限的，如果磁盘驱动器超载，到这些磁盘驱动器的I/O操作就要排队，SQL的I/O延迟将很长。这可能会使锁持续的时间更长，或者使线程在等待资源的过程中保持空闲状态，其结果就是整个系统的性能受到影响。DBMS的硬件相关配置：l分页机制：一个页中所能存放的行的数目也是值得考虑的一个方面，如DB2为页宽提供了很多选项（4KB、8KB、16KB和32KB）。如果行的长度很小，或者对数据的访问基本上是随机的，则更默认选项4K是恰当的。不过，在有些情况下，如一

22、个表中各行的长度要大于4KB，或对于一条固定长度的记录总长度可能刚好比4KB的一半大一点点，这时一个页只能容纳一条记录。这种设计不仅浪费空间，而且对于很多操作还需要消耗更多的资源。因此对于这一类的记录，应该考虑使用更大的页宽，这样浪费的空间相对要少一些。l在SQL Server中，利用段（2000以后改为文件组）可以把一个表放在某个物理设备上，把它的不分簇索引放在一个不同的物理设备上，这样能提高性能。尤其是系统采用了多个智能型磁盘控制器和数据分离技术的情况下，这样做的好处更加明显。同样的，用SQL Server段把一个频繁使用的大表分割开，并放在多个单独的智能型磁盘控制器的数据库设备上，这样也

23、可以提高性能。因为有多个磁头在查找，所以数据分离也能提高性能。用SQL Server段把文本或图像列的数据存放在一个单独的物理设备上可以提高性能。一个专用的智能型的控制器能进一步提高性能。l填充因子：数据库在处理索引文件时是按分页机制来实现的，目的是提高效率，每个页会预留空间以便未来增加新索引内容页无需进行大量的页面操作，此空间的比例称为填充因子。在SQL SERVER中，如果向已满的索引页添加新行，数据库引擎 将把大约一半的行移到新页中，以便为该新行腾出空间。这种重组称为页拆分。页拆分可为新记录腾出空间，但是执行页拆分可能需要花费一定的时间，此操作会消耗大量资源。此外，它还可能造成碎片，从而

24、导致 I/O 操作增加。正确选择填充因子值可提供足够的空间以便随着向基础表中添加数据而扩展索引，从而减少页拆分可能性。填充因子的设置需要DBA的经验。四、客户端优化l对数据库访问而言，基本的架构是C/Sl客户端性能优化的关键是优化查询，以减少查询的资源利用（减少通讯量和服务器运算量）。l（）把频繁使用的小表放在内存或高速缓存中，可以明显减少/。l（）减少所读的行数和所读或更新的列。如，仅读取满足条件的第一条记录，仅读取或更新必须的列。l（）用临时表缩小查询范围。l（）尽量避免子查询和明确关联的子查询。l（）避免复杂规则表达式。l（）尽量使用数据库引擎提供的函数，如：，。l（）尽量使用连接而不用

25、嵌套循环，避免连接长字符串。l（）尽量用缩小连接范围。l（）避免不必要的大表的全表搜索。程序员首先要做的事l了解业务逻辑与用户需求l了解数据库的逻辑设计与物理设计l了解DBA对数据库的配置：分页大小、填充因子、聚集索引等排序优化l排序操作是一种费时操作，以下情况会发生排序处理：SQL中包含group by子句SQL中包含order by子句SQL中包含distinct子句SQL中包含minus或union操作l利用索引简化排序可大大提高性能当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序这个步骤。为了避免不必要的排序，就要正确地增建索引。在SQL Server中，使用聚集索引排序输

26、出的效率是最高的，因为其本身就是物理方式组织的。l合理地合并数据库表（尽管有时可能影响表的规范化，但相对于效率的提高是值得的）。如果排序不可避免，那么应当试图简化它，如缩小排序的列的范围等。查询优化l利用索引来避免全表扫描是一种最有效的查询优化方法。l什么样的SQL语句是劣质SQL语句？导致建有索引的表仍按全表搜索的方式查询的SQL查询。l是否使用索引？根据某些专家的经验，使用索引范围扫描的原则是：对于数据有原始排序的表，读取少于表记录数40%的查询应该使用索引范围扫描。对读取多于表记录数40%的查询应全表扫描。对于未排序的表，读取少于表记录数7%的查询应该使用索引范围扫描，反之，对读取多于表

27、记录数7%的查询应全表扫描。注：在不同的观点中，对是否使用索引的读取记录的百分比值不太一致，基本上是一个经验值，但是读取记录的百分比越低，使用索引越有效。l什么SQL查询会使用索引？ 一般而言DBMS的优化器会尽可能的利用索引提高效率，但存在下面情况的SQL不会用到索引：存在数据类型隐形转换的；列上有运算的；使用不等于(，NOT)运算的；使用substr等函数的；通配符在第一个字符的；字符串连接(|)的等等。l避免列的计算 任何对列的操作都可能导致全表扫描，这里所谓的操作包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等式的右边，甚至去掉函数。 例：在ORACLE系统中，下列SQL条件

28、语句中的列都建有恰当的索引，但30万行数据情况下执行速度却非常慢：select * from record where substr(CardNo,1,4)=5378(13秒) select * from record where amount/30 1000（11秒） select * from record where to_char(ActionTime, yyyymmdd) = 19991201（10秒） 由于where子句中对列的任何操作结果都是在SQL运行时逐行计算得到的，因此它不得不进行表扫描，而没有使用该列上面的索引；如果这些结果在查询编译时就能得到，那么就可以被SQL优化器优

29、化，使用索引，避免表扫描，因此将SQL重写如下： select * from record where CardNo like 5378%（ 1000*30（ 1秒）select * from record where ActionTime = to_date (19991201 ,yyyymmdd)（10应该写为： select col1,col2 from tab1 where col110l尽量去掉IN、OR 含有IN、OR的Where子句常会使用工作表，使索引失效；如果不产生大量重复值，可以考虑把子句拆开；拆开的子句中应该包含索引。 例：select count(*) from stu

30、ff where id_no in(0,1)（23秒）可以考虑将or子句分开： select count(*) from stuff where id_no=0 select count(*) from stuff where id_no=1然后再做一个加法，与原来的SQL语句相比，查询速度更快。例：对于非count统计，可以用union代替or，如：select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=2004-9-16 or gid9990000用时：68秒改为：select gid,fariqi,nei

31、buyonghu,reader,title from Tgongwen where fariqi=2004-9-16 unionselect gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid9990000 用时：9秒l尽量去掉 和NOT 尽量去掉 ，避免全表扫描，如果数据是枚举值，且取值范围固定，则修改为OR方式。例：UPDATE SERVICEINFO SET STATE=0 WHERE STATE0;以上语句由于其中包含了，将导致全表扫描而没有用到state字段上的索引。实际应用中，由于业务逻辑的限制，字段state为枚

32、举值，只能等于0，1或2，而且，值等于=1，2的很少，因此可以去掉，利用索引来提高效率。修改为：UPDATE SERVICEINFO SET STATE=0 WHERE STATE = 1 OR STATE = 2 再看下面这个例子： select * from employee where salary 3000; 对这个查询，可以改写为不使用： select * from employee where salary3000;llike子句尽量前端匹配 因为like参数使用的非常频繁，因此如果能够对like子句使用索引，将很高的提高查询的效率。例：select * from city whe

33、re name like %S%以上查询用了全表扫描，如果能够修改为：select * from city where name like S%那么查询成功的利用了name字段的索引，效率也会大大提高。又例如： SELECT * FROM customer WHERE zipcode LIKE 98_ 即使在zipcode字段上已建立了索引，在这种情况下也还是采用顺序扫描的方式。如果把语句改为： SELECT * FROM customer WHERE zipcode 98000 在执行查询时就会利用索引来查询，显然会大大提高速度。l分解子查询 如果需要从子查询中获取结果作为主查询的条件，可能

34、的情况下可以分解为两个查询，将子查询的结果获取后，作为常量加入第二个查询的WHERE条件从而实现索引的使用。如查询工资大于平均数的员工，可以先查询出平均数，再进行第二个查询。经常在论坛中看到如“能不能用一个SQL写出.”的贴子，殊不知复杂的SQL往往牺牲了执行效率。l尽量去掉Where子句中的IS NULL和IS NOT NULL Where字句中的IS NULL和IS NOT NULL将不会使用索引而是进行全表搜索，因此需要通过改变查询方式，分情况讨论等方法，去掉Where子句中的IS NULL和IS NOT NULL。因为NULL值表示空值，即不确定的值，数据库不会为其生成索引。l逆向思维

35、：怎样避免使用索引呢？select * from serviceinfo where DisposalCourseFlag + 0 = 6l除了索引之外，其他的优化？l字段提取要按照“需多少、提多少”的原则，避免“select *”以下是在SQL Server中的一个试验： select top 10000 gid,fariqi,reader,title from tgongwen order by gid desc用时：4673毫秒select top 10000 gid,fariqi,title from tgongwen order by gid desc用时：1376毫秒select

36、top 10000 gid,fariqi from tgongwen order by gid desc用时：80毫秒 l由此看来每少提取一个字段，数据的提取速度就会有相应的提升。提升的速度还要看您舍弃的字段的大小来判断。lCount统计函数需要根据实际数据来检验 在某些实验中发现： select count(*) from Tgongwen用时：1500毫秒select count(gid) from Tgongwen 用时：1483毫秒select count(fariqi) from Tgongwen用时：3140毫秒select count(title) from Tgongwen用时

37、：52050毫秒 l从以上可以看出，如果用count(*)和用count(主键)的速度是相当的，而count(*)却比其他任何除主键以外的字段汇总速度要快，而且字段越长，汇总的速度就越慢。而在另一些实验中发现count(*)比使用单独字段要慢，因此在实验的数据库开发中，应该根据实验测试来决定。lON，WHERE与HAVING 避免使用HAVING子句， HAVING 只会在检索出所有记录之后才对结果集进行过滤。这个处理需要排序，总计等操作，如果能通过WHERE子句限制记录的数目，那就能减少这方面的开销。 HAVING 中的条件一般用于对一些集合函数等无法用WHERE限制的条件的比较，如COUNT() 等等。除此而外，一般的条件应该写在WHERE子句中。 在多表联接查询时，ON比WHERE更早起作用。系统首先根据各个表之间的联接条件，把多个表合成一个临时表后，再由WHERE进行过滤，然后再计算，计算完后再由HAVING进行过滤。由此可见，要想过滤条件起到正确的作用，首先要明白这个条件应该在什么时候起作用，然后再决定放在那里。例:低效:SELECT REGION FROM LOCATION GROUP BY REGION HAVING REGION != SYDNEY AND REGION != PERTH高效SELECT