数据库查询优化（精选12篇）
数据库查询优化 篇1
数据库系统作为管理信息系统的核心, 各种基于数据库的联机事务处理以及联机分析处理正慢慢地转变成为计算机应用的最为重要的部分, 根据以往大量的应用实例来看, 在数据库的各种操作中, 查询操作所占的比重最大, 而在查询操作中基于SELECT语句在SQL语句中又是代价最大的语句。
一、基于索引的优化
数据库的优化方法多种多样, 不同的方法对提高数据库查询效率也不相同。
索引作为数据库中的重要数据结构, 它的根本目的就是为了提高查询的效率。而优化查询的重要方法就是建立索引, 建立适合关系数据库系统的索引, 这样就可以避免表扫描, 并减少了因为查询而造成的输入输出开销, 有效提高数据的查询速度, 优化了数据库性能。
1.判断并建立必要的索引 对所要创建的索引进行正确的判断, 使所创建的索引对数据库的工作效率提高有所帮助。为了实现这一点, 我们应做到以下要求:在熟记数据库程序中的相关SQL语句的前提下, 统计出常用且对性能有影响的语句;判断数据库系统中哪些表的哪些字段要建立索引。 2.对索引使用的一些规则 索引的使用在一些大型数据库系统中会经常使用到, 这样可以有效的提高数据库性能, 使数据库的访问速度得到提高。但索引的使用要恰倒好处, 所以我们在使用索引时应遵守使用原则:建立索引可以提高数据库的查询速度, 但索引过多, 不但不能实现优化查询, 反而会影响到数据库的整体性能。索引作为数据库中实际存在的对象, 每个索引都要占用一定的物理空间。所以对于索引的建立要考虑到物理空间容量, 以及所建立索引的必要性和实用性。 3.合理的索引对SQL语句的意义 索引建立之后, 还要确保其得到了真正的使用, 发挥了其应有的作用。首先, 可以通过SQL语句查询来确定所建立的索引是否得到了使用, 找出没有使用到的索引。其次, 索引得到使用以后, 是否得到了预期的效果, 对数据库的性能是否实现了真正意义上的提高, 只有合理的索引才能真正提高数据库的性能。
二、优化SQL语句
在使用索引时可以有效的提高查询速度, 但如果SQL语句使用不恰当的话, 所建立的索引就不能发挥其作用。所以我们应该做到不但会写SQL, 还要写出性能优良的SQL语句。下面, 就如何优化引用例子进行说明。 首先, 在进行查询时, 返回的值应该是查询所需要的。在查询中应该尽量减少对数据库中的表的访问行数, 使查询的结果范围最小, 这就意味着在查询时, 不能过多的使用通配符, 如:select*from table1语句, 而应该做到最小化查询范围, 要查询几行几列就选择几行几列, 如:select col1 from table1;多数情况下, 用户并不需要查询到的所有数据, 而只是部分或靠前的数据时, 我们也可以通过SQL语句来进行限制查询的结果, 如:select top 50 col1 from table1。 其次, 对于一些特殊的SQL语句, 在使用时应正确选择。我们用一组例子来说明, 如:EXISTS, NOT EXISTS。
语句一:select sum (t1.c1) from t1 where ( (select count (*) from t2 where t2.c2=t1.c2) >0)
语句二:select sum (t1.c1) from t1 where exists (select*from t2 where t2.c2=t1.c1)
两个语句所得到的结果相同, 但, 语句二的效率要远高于语句一, 因为语句一在查询中产生了大量的索引扫描。 在对数据库查询时, 所使用的语句多种多样, 但选择恰当的语句能够有效的提高查询效率。
最后, WHERE子句在使用时应该注意的问题。
在WHERE子句中可以使用exist 和not exist代替in和not in。应该尽量避免使用in, not in, or 或者having。可以使用表链接代替 exist。Having可以用where代替, 如果无法代替可以分两步处理。
三、其他优化方法
数据库的查询优化方法不仅仅是索引和SQL语句的优化, 其他方法的合理使用同样也能很好的对数据库查询功能起到优化作用。如以下几种方法。
1.避免或简化排序 应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时, 优化器就避免了排序的步骤。 2.避免相关子查询 如果在主查询和WHERE子句中的查询中同时出现了一个列的标签, 这样就会使主查询的列值改变后, 子查询也必须重新进行一次查询。因为查询的嵌套层次越多, 查询的效率就会降低, 所以我们应当避免子查询。否则, 就要在查询的过程中过滤掉尽可能多的。 3.创建使用临时表 在表的一个子集进行排序并创建临时表, 也能实现加速查询。在一些情况下这样可以避免多重排序操作。但所创建的临时表的行要比主表的行少, 其物理顺序就是所要求的顺序, 这样就减少了输入和输出, 降低工作量, 提高了效率, 而且临时表的创建并不会反映主表的修改。 4.用排序来取代非顺序存取 磁盘存取臂的来回移动使得非顺序磁盘存取变成了最慢的操作。但是在SQL语句中这个现象被隐藏了, 这样就使得查询中进行了大量的非顺序页查询, 降低了查询速度, 对于这个现象还没有很好的解决方法, 只能依赖于数据库的排序能力来替代非顺序的存取。
四、结论
对于数据库的优化, 我们要抓住关键问题, 提出改善查询效率, 这样才能真正使数据库服务得到根本提高。本文在对数据库查询优化的方法上, 进行了分析, 提出了部分见解, 有效的提高数据库查询效率。
数据库查询优化 篇2
一、利用EXPLAIN关键字来评估查询语句中的缺陷
如下图所示，现在笔者在数据库中执行了一条简单的Select查询语句，从一个表格中查询所有信息。现在数据库管理员想知道，数据库在执行这条语句时，做了哪些工作?或者说想知道，这条查询语句有没有进一步优化的可能。如果要了解这个信息的话，就可以在查询语句中加入一个Explain关键字。
通过Select查询语句可以从数据库中查询某个表中的数据。但是这条语句执行的效率如何?是否还有优化的余地?这些内容是无法从上面这个简单的查询语句中获得的。为了了解更加详细的信息，需要加入Explain关键字。如下图所示： 加入Explain关键字之后，系统并没有查询出表格中的数据，而只是显示了查询过程中的一些信息。这些信息对于我们后续进行数据库查询优化非常有帮助。从上面这个信息中我们可以看出，用户只是进行来一个简单的查询。在这个查询中，没有用到任何索引、关键字等内容，也没有用到Where条件语句。为此这个查询语句并不是很合理。虽然其可以找到最后正确的结果，不过其查询效率可能并不是很明显。为此数据库专家可以根据上面显示的信息来进行优化。如果我们现在在查询语句中加入一条Where语句，那么又会有什么样的结果呢?如下图所示。 此时在最后一个Extra字段中，系统就会显示已经使用了Where语句。在进行数据库优化中，我们需要抓住结果中的NULL字段或者空白内容的字段。这些地方往往是我们进行优化的重点。如上图所示，我们可以给这条Select语句进行如下的优化：在表中设置关键字或者索引，来提高查询的效率。二、数据比较时采用相同类型的列以提高查询效率
在数据查询时，有时候会在条件语句中加入判断的条件。如现在有两张表：用户基本信息表和用户权限表，两者通过用户编号作为关联。现在需要查询出每个用户对应什么样的权限，此时就要通过用户编号作为查询条件来进行查询。现在假设用户基本信息表中的用户编号字段为CHAR类型的;而用户权限表中的用户编号是VARCHAR类型的。这两个数据类型虽然都是字符型，但是不是同一种类型。现在对这连个表执行关联查询，其查询的效率如何呢?首先需要确定的一点是，虽然他们两个是不同类型的字符型数据，不过是相互兼容的。最后仍然可以得到正确的结果。明确了这一点之后，我们再来考虑，能否对这个查询语句进行优化呢?
我们再假设一下。现在这两个表的用户编号的数据类型都是CHAR，
现在再对这两个表进行关联查询，得到的结果是否相同呢?我们测试的结果是，查询的结果是相同的，但是其所花费的时间是不同的。而且随着数据量的增加，两个查询所相差的时间会越来越长。从这里可以知道，虽然这两个查询语句是等价的，但是其查询的效率不同。
在MySQL数据库中，虽然相互兼容的数据类型可以进行相互比较。但是其查询的效率会有所影响。从提高数据库查询效率的角度出发，笔者建议在查询条件语句中最好比较具有相同类型的列。在同等条件下，相同的列类型比不同类型的列能够提供更好的性能。特别是在数据量比较多的数据库中，这尤其重要。
不过这个优化需要涉及到数据表的列类型。为此在数据表进行设计时，就需要考虑这一点。如针对上面这个案例，我们可以在两个表中专门设置一个用户ID列。可以使用整数类型的序列，让系统进行自动编号。然后在查询时通过这个用户ID列来进行比较，而不是通过原来的用户编号列进行比较。相对来说，这么操作查询的效率会更高。
三、在Like关键字的起始处通配符要谨慎使用
在实际工作中，笔者发现不少数据库管理员有一个不好的习惯。他们在使用Like等关键字时，通配符会乱用。如现在用户需要查找所有以“LOOK”为前缀的产品信息。用户在查询时，会习惯性的使用下面的语句进行查询：like “%LOOK%”。这个条件语句会查询出所有品名中有LOOK这个单词的纪录，而不是查询出以LOOK为前缀的产品信息。
虽然最终的结果可能是相同的。但是两者的查询效率不同。其实这很大一部分原因是客户端应用程序设计不当所造成的。如在客户端应用程序设计时，系统会默认显示一个%符号。如下图所示。
这么设计的本意是好的，让系统能够支持模糊查询。但是用户在实际操作起来，就可以有问题。如用户在查询时，不会在%号前面输入LOOK这个单词，而是在%后面输入LOOK这个单词。因为在查询时，光标会自动定位到%号后面。通常情况下，用户在输入时不会再去调整光标的位置。此时就出现了上面所说的这种情况。为此笔者建议，在Like等关键字后面如果需要用到通配符的话，要非常的谨慎。特别是从大量数据中查找纪录时，这个通配符的位置一定要用对地方。在起始处能够不同通配符的话，尽量不要使用通配符。
四、尽量使用其它形式来代替Like关键字
上面提到在使用Like关键字时需要注意通配符的位置。其实从查询效率来看，我们不仅需要注意通配符的位置，而且能够不用Like关键字最好就不用。其实在SQL语句中，可以利用其他方式来代替Like关键字。如现在有一个产品表，其编号为6位。现在需要查询以9开头的产品编号。这该怎么操作呢?
一是可以通过使用Like关键字，如LIKE “9%”。注意这个通配符的位置。这个条件语句可以查到所需要的结果。但是从性能优化的角度看，这条语句不是很好的处理方式。我们还可以通过一些折中的方式来实现。
数据库查询优化 篇3
关键词：海量数据；多数据库；表分区；分表技术
中图分类号：TP311.131文献标识码：A文章编号：1007-9599 （2010） 14-0000-03
Massive Data Query Optimization Research and Application Based on Data Partition
Jia Junkai1,Xu Hui1,Gu Guoqiang1、2
(1.Donghua University,School of Computer Science,Shanghai200051,China;2.Shanghai Triman Informatin&Technology Co.,Ltd.,Shanghai200051,China)
Abstract:The low efficiency of massive data data query,comparison and analysis of a variety of massive data query optimization solutions,advantages and disadvantages,division massive data based on data query performance optimization.The method uses multi-database processing,table partitioning,sub-table technology will be in three dimensions the data stored in the data division,reducing the size of massive data queries.After large-scale experiments that the method improves the efficiency of massive data queries.
Keywords:Massive data;Multi-database;Table partition;Points table technology
在面对海量数据时，用户关心的是如何从其中查询出对自己有价值的信息而非海量数据本身，如何使查询海量数据的性能更为高效是目前国内外数据库系统研究的热点问题。
在海量数据查询优化策略有：一：代数优化；它对查询语句进行变换以减少语句执行开销[1]。二：规则优化；它是根据启发式规则选择执行策略[2]。两种方法的不足表现在：当数据量规模超出系统软硬件处理能力时，通过优化语句很难提升查询性能。三：物理优化；它是选择合适的存储策略进行的优化，但是在对语句的执行效率考虑不足。四：代价估算优化。它是对已经存的优化策略进行代价估算，选择最小的执行代价策略[3]。不足：计算最小执行代价耗费时间过多且实用性不高。
目前的海量数据查询性能低下大都是由于数据的规模超出系统的软硬件处理能力。本文利用多数据库中间件插件技术在存储海量数据时将数据划分存储到多个自治的数据库中，在一维上降低数据规模并优化查询语句；在本地数据库中运用表分区技术，将海量数据划分存储到多个表分区中，在二维上降低海量数据的规模；利用分表措施将分区表分成多个子表，再次降低海量数据的规模。通过对海量数据的三维划分、优化查询语句以及降低数据的扫描规模提高了海量数据的查询性能。
一、数据划分
数据划分是指按照某种规则将数据分布到特定范围内，使得在对数据进行查询时系统并行处理能力提高，以此降低查询的响应时间，提高数据库的查询性能。数据划分对于能否充分利用系统的cpu和带宽资源，减少通信开销，平衡系统负载和减少计算量，最佳的发挥并行性和系统性能至关重要[4]。
（一）多数据库并行处理技术
多数据库并行处理技术是以中间件为技术支撑，对海量数据进行合理存储，高效查询的一种技术。多数据库并行处理结构如图a所示：
当用户提出加载请求时，通过负载均衡系统将请求均衡的分发给并行加载服务，并行加载服务首先读取全局数据字典中的元数据，通过数据划分器和表加载器将数据加载到底层数据库中，当用户提出的查询服务时，系统将请求发给并行查询服务，并行查询服务首先读取全局数据字典用于获得多数据库的配置信息，然后通过查询语句改写服务优化查询语句并发送给查询服务器，用以完成数据的查询功能。
多数据库并行查询技术通过中间层组件对查询语句进行分析、优化，根据分析的结果将查询分解或者复制为多个等价的子查询，将多个子查询语句在相应的数据库节点上执行，它降低了每个本地数据库的查询规模，并实现查询的本地化并行查询，提高了数据的查询效率。
（二）表分区
针对底层数据库数据查询规模大的问题，对其特定业务的查询条件属性做表分区，以提高查询的性能。图b为根据时间将底层数据库中的数据进行表分区的示意图。
由图可知，经表分区后，数据在数据库中按一定的规律存放。当进行数据查询时，系统只需扫描存放数据的响应表分区，因而查询扫描规模可以大大降低，数据查询性能也会得到相应的提高。
当分区的规模较大时，在海量数据库中无法有效降低数据规模，这样的数据划分无意义；当用户分区规模较小时，在进行多数据查询时，会涉及到多个表分区，查询性能也难以提高。因此表分区的粒度需要优先考虑两方面：一是数据的存储规模；二是用户的查询粒度。
（三）分表技术
1.原理。
在分区表的基础上，将表根据所查找的属性字段划分成为多个子表，利用数据库的Union ALL视图将需要查询的子表动态的合并起来，使对原表的查询转化为对视图或者子表的查询，以此降低数据查询的扫描规模。
2.算法。
输入：业务层提交给中间层的查询语句；
输出：语句改写后的查询语句；
流程：
（1）将业务层提交的查询语句提交给语法分析器；通过语法分析器截取where子句后的条件表达式。
（2）分析条件表达式中是否含有与分表字段有关的条件。当不包含分表字段时返回原语句，算法结束；否则提取该字段。
（3）根据提取的字段分析其涉及到的数据范围，找到相对应的视图或者子表。
（4）将原语句中from子句后的原表改为3得到的视图或者子表，此时得到查询语句a。
（5）去除a中与分表有关字段的条件，返回改写后的查询语句，算法结束。
二、数据划分性能分析
（一）数据库级别的数据划分
通过中间件，将复杂查询语句转化为简单查询，将的串行查询改为在各个本地库上的并行查询。如果将数据分布到各个数据库中，此时需要的网络和磁盘I/O开销会非常的大，通过中间组件服务在数据加载时预先进行数据布局，在对大规模的数据进行处理的时候，不需要将中间结果在局部数据库之间的网络上进行传输，可以极大提高并行处理的性能。
（二）数据库表级别的数据划分
为更好的分析数据划分对查询性能的作用，建立以下场景：设有结构为TB{RID，CSDZ，XZDZ，CJSJ，NRXX}的表，RID为主键，CSDZ和XZDZ为二维空间属性，其各自的值域为0-31，CJSJ为时间属性，NRXX为内容信息属性。
通过表分区的方式将其按照时间来进行数据划分。由于数据量大并且查询针对小时范围较为频繁，选取按小时对海量数据进行表分区。
不考虑物理存储的条件下：
假设a查询扫描同等数据规模所花费的时间相同。
假设b查询的响应时间仅仅考虑数据的扫描时间。
假设c查询数据划分的各部分时能充分并行。
对于基于表分区的数据划分：
查询时间间隔为n小时的数据时，理想条件下，数据被平均的分成24分，这样查询扫描的数据在规模上减少到n/24；在假设a和假设b的条件下，查询的响应时间会减少到n/24，在查询性能上提高了24/n倍。实际情况下，数据不可能被完全的平分，这样查询扫描的数据在最坏情况下受到最大表分区规模的制约。
对于基于分表的数据划分：
设关系R为CSDZ和XZDZ之间组成的关系，关系R可以划分成多个子关系Rc_x，在CSDZ和XZDZ的数据划分基础上，针对全表的查询，在假设c成立的条件下，其查询性能受限于最大子关系的数据规模上。假设最大子关系的数据规模为m，总的数据规模为v，在上述假设都成立的情况下，查询性能的响应时间减少为原来的m/v，性能提高了v/m；考虑数据结果合并的开销，设原来查询相应时间为T，查询处理时间为T1，查询合并时间为T2，则T=T1+T2。基于上述分析，T1的时间减少为原来的m/v，查询合并时间不变，则经过数据划分后查询的响应时间为m/v*T1+T2，其查询性能提升T1+T2/（m/v*T1+T2）。
在考虑物理存储的条件下：
假设rownum为原表中信息总数，length为每条记录的长度，k为子关系的个数，ROWNUMi为子关系i的信息总数。在数据划分之前，设q为查询的总时间复杂度，则q=O（rownum*length）。设q1为数据划分后的查询总时间复杂度，q2为所有子关系的查询时间复杂度总和，q3为返回合并结果的时间复杂度。则q1=q2+q3。因海量数据查询时查询的响应时间远远大约返回合并结果的时间复杂度，即q3< 三、海量数据划分策略的总体架构 通过对数据划分的理解以及对数据划分性能的分析，本文提出基于数据划分策略的海量数据查询模型总体架构分为如图c所示： 底层是各种异构数据库，通常我们称之为“本地数据库”；此层主要用来存放海量数据，并在此层实现表分区、分表的数据划分。中间层是一个基于CORBA标准的事务处理“中间件”层。它的作用是优化数据的存储结构，改写语句的执行策略。上层为业务层，为中间层提供数据和查询语句来源。 该架构数据划分存储到多个自治的数据库中并优化查询语句的执行效率，在底层数据库中用表分区、分表减少数据规模以期提高查询效率。 四、试验 试验一： 试验方案：在公安系统中的oracle9i数据库中选取一组集群，在集群中建立一张TB表，同时建立1000张与TB表相同表结构的子表，其表命名为TB1-TB1000。将数据量为1TB的数据导入到TB表中，并将这1TB的数据平均划分然后导入到1000张子表中，同时将子表动态的组成一张和TB表相同的视图。对TB表和视图分别进行大规模数据查询。 本试验的目的在于测试相同数据规模下单表查询和对多表建立的视图查询的数据查询性能对比，因此在视图查询时不采用并行查询方式，仅测试多表建立的全局视图对查询性能的影响。 试验结果：在数据规模都在80000万的条件下，在串行条件下，对无索引的时间进行顺序扫描，单表扫描的时间大约为十五至二十分钟多分钟，而对分表建立的索引所花费时间要超过二十五分钟；对分表属性进行查询时，二种方式的查询都不超过三分钟。当调整查询方式为并行查询，并行度为10时，对时间的扫描，二者都约三分钟。对内容字段的查询，二者在查询性能上差别不大。 试验结论：在相同规模的海量数据情况下，虽然通过对分表建立统一视图会导致存储空间的增大，但是不明显。并行全视图扫描在查询性能和单表查询达到相同的水平，因而得出结论分表视图的方案可行。 试验二： 方案：在试验一得基础上，通过中间件的并行查询服务对TB表进行单向匹配、双向匹配、不同属性值之间组合的统计查询。 试验结果： 结果分析：在三类查询中除测试c中的一般查询外，分表后的查询相应时间都比为分表后的响应时间短。测试c的一般查询涉及到未进行分表的内容字段，此时会受到文本索引的影响，同时查询结果会在局部的数据库之间传递，此时网络通信时间会占据数据查询响应时间的大部分时间。在对常用的分表字段进行条件查询时，因对数据的扫描规模降低，数据查询相应时间会小于未分表的查询相应时间。进而证实了多维数据划分查询优化方法的可行性。 五、结论 通过对海量数据查询的优化与性能的分析，基于数据划分策略的海量数据优化方法解决了因数据规模在系统的软硬件处理能力之外所造成的数据查询性能低的问题。查询性能得到大幅提升。 数据划分中的分表技术将原表转为子表，子表太多会使系统I/O的次数剧增，造成数据查询性能降低。因此我们要不断的总结、探索找到子表个数的峰值，使得系统充分利用并行性的时候数据的查询性能最高。 参考文献： [1]朱宁贤.数据库查询的优化策略探讨.办公自动化杂志,2007,8 [2]王能斌.数据库系统.电子工业出版社,1998 [3]韩忠,汪伟.海量数据的查询优化.科技资讯,2006,10 [4]侯潇.海量数据处理中基于数据划分的查询优化研究与实现,2007,11 [5]陈光.多数据库事务处理策略的研究,2000,4 数据库的优化方法多种多样, 不同的方法对提高数据库查询效率也不相同。 索引作为数据库中的重要数据结构, 它的根本目的就是为了提高查询的效率。而优化查询的重要方法就是建立索引, 建立适合关系数据库系统的索引, 这样就可以避免表扫描, 并减少了因为查询而造成的输入输出开销, 有效提高数据库数据的查询速度, 优化了数据库性能。然而在创建索引时也增加了系统时间和空间的开销。所以创建索引时应该与实际查询需求相结合, 这样才能实现真正的优化查询。 1.1 判断并建立必要的索引 对所要创建的索引进行正确的判断, 使所创建的索引对数据库的工作效率提高有所帮助。为了实现这一点, 我们应做到以下要求:在熟记数据库程序中的相关SQL语句的前提下, 统计出常用且对性能有影响的语句;判断数据库系统中哪些表的哪些字段要建立索引。其次, 对数据库中操作频繁的表, 数据流量较大的表, 经常需要与其他表进行连接的表等, 要进行重点关注。这些表上的索引将对SQL语句的性能产生重要的影响。 1.2 对索引使用的一些规则 索引的使用在一些大型数据库系统中会经常使用到, 这样可以有效的提高数据库性能, 使数据库的访问速度得到提高。但索引的使用要恰倒好处, 所以我们在使用索引时应遵守使用原则:建立索引可以提高数据库的查询速度, 但索引过多, 不但不能实现优化查询, 反而会影响到数据库的整体性能。索引作为数据库中实际存在的对象, 每个索引都要占用一定的物理空间。所以对于索引的建立要考虑到物理空间容量, 以及所建立索引的必要性和实用性。 1.3 合理的索引对S Q L语句的意义 索引建立之后, 还要确保其得到了真正的使用, 发挥了其应有的作用。首先, 可以通过SQL语句查询来确定所建立的索引是否得到了使用, 找出没有使用到的索引。分析索引建立但没有使用的原因, 使其真正发挥作用。其次, 索引得到使用以后, 是否得到了预期的效果, 对数据库的性能是否实现了真正意义上的提高, 只有合理的索引才能真正提高数据库的性能。 2 优化SQL语句 在使用索引时可以有效的提高查询速度, 但如果SQL语句使用不恰当的话, 所建立的索引就不能发挥其作用。所以我们应该做到不但会写SQL, 还要写出性能优良的SQL语句。下面, 就如何优化引用例子进行说明。 首先, 在进行查询时, 返回的值应该是查询所需要的。在查询中应该尽量减少对数据库中的表的访问行数, 使查询的结果范围最小, 这就意味着在查询时, 不能过多的使用通配符, 如:select*from table1语句, 而应该做到最小化查询范围, 要查询几行几列就选择几行几列, 如:select col1 from table1;多数情况下, 用户并不需要查询到的所有数据, 而只是部分或靠前的数据时, 我们也可以通过SQL语句来进行限制查询的结果, 如:select top 50 col1 from table1。 其次, 对于一些特殊的SQL语句, 在使用时应正确选择。我们用一组例子来说明, 如:EXISTS, NOT EXISTS。 语句一:select sum (t1.c1) from t1where ( (select count (*) from t2 where t2.c2=t1.c2) >0) 语句二:select sum (t1.c1) from t1 where exists (select*from t2 where t2.c2=t1.c1) 两个语句所得到的结果相同, 但, 语句二的效率要远高于语句一, 因为语句一在查询中产生了大量的索引扫描。 在对数据库查询时, 所使用的语句多种多样, 但选择恰当的的字句能够有效的提高查询效率。 最后, WHERE子句在使用时应该注意的问题。 在WHERE子句中可以使用exist和not exist代替in和not in。应该尽量避免使用in, not in, or或者having。可以使用表链接代替exist。Having可以用where代替, 如果无法代替可以分两步处理。 3 其他优化方法 数据库的查询优化方法不仅仅是索引和SQL语句的优化, 其他方法的合理使用同样也能很好的对数据库查询功能起到优化作用。我们就来列举几种简单实用的方法。 3.1 避免或简化排序 应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时, 优化器就避免了排序的步骤。 3.2 避免相关子查询 如果在主查询和WHERE子句中的查询中同时出现了一个列的标签, 这样就会使主查询的列值改变后, 子查询也必须重新进行一次查询。因为查询的嵌套层次越多, 查询的效率就会降低, 所以我们应当避免子查询。如果无法避免, 就要在查询的过程中过滤掉尽可能多的标签。 3.3 创建使用临时表 在表的一个子集进行排序并创建临时表, 也能实现加速查询。在一些情况下这样可以避免多重排序操作。但所创建的临时表的行要比主表的行少, 其物理顺序就是所要求的顺序, 这样就减少了输入和输出, 降低了查询的工作量, 提高了效率, 而且临时表的创建并不会反映主表的修改。 3.4 用排序来取代非顺序存取 磁盘存取臂的来回移动使得非顺序磁盘存取变成了最慢的操作。但是在SQL语句中这个现象被隐藏了, 这样就使得查询中进行了大量的非顺序页查询, 降低了查询速度, 对于这个现象还没有很好的解决方法, 只能依赖于数据库的排序能力来替代非顺序的存取。 4 结语 对于数据库的优化, 我们要抓住关键问题, 提出改善查询效率, 这样才能真正使数据库服务得到根本提高。本文在对数据库查询优化的方法上, 进行了分析, 提出了部分见解, 有效的提高数据库查询效率。 参考文献 [1]王珊, 孟小峰.数据库系统导论 (第七版) [M].机械工业出版社, 2000, 10 [2]王磊, 王熙宁.网上考试系统的性能与安全分析[J].情报科学, 2004 (22) . < % Dim NumVisits NumVisits=0 Application.Lock Application(“NumVisits”) = Application(“NumVisits”) + 1 Application.Unlock %> 欢迎光临本网页，你是本页的第 < %= Application(“NumVisits”) %>位访客 ! 在这段程序中，如果你试图通过改变变量 NumVisits 的值来改变记数器结果，是绝对办不到的，因为用变量的值去改变 Application 的值是不可以的，这两者是不相关的。所以这里对变量的定义和赋值都是多余的。那么我们究竟应该如何来给 Application(“NumVisits”) 定义一个初始值呢?请看以下修正后程序： < % If Application(“NumVisits”)< 999 then Application(“NumVisits”)=999 End If Application.Lock Application(“NumVisits”)=Application(“NumVisits”)+1 Application.Unlock %> 欢迎光临本网页，你是本页的第 < %= Application(“NumVisits”) %>位访客 ! 这里的 999 就是你要设定的计数器初始值，如此一来问题就迎刃而解了。我非常感谢这位姓康的朋友给我指出了这个错误，虽然这只是一个很小的漏洞，但我们在共同学程序写程序的过程中非常需要这种严谨细致的作风，希望今后朋友们们一旦发现文中的错误即刻来信告知，我也能及时纠正，谢谢。 SQL 语言可以分为两大部分：数据定义语言和数据操纵语言，继上一篇我们学习了数据操纵语言中的 Select 语句后，今天作者要继续给大家简要介绍其余的 SQL 语句。 SQL 是一种完备的数据处理语言，不仅用于数据库查询，而且用于数据库中的数据修改和更新，与支持 SQL 查询的 Select 语句的复杂性相比较，更改数据库内容的 SQL 语句就格外简单。然而对于一个 DBMS 来说，数据更新所造成的风险大大超出了数据查询。数据库管理系统必须在更改期内保护所存储的数据的一致性，确保有效的数据进入数据库，数据库必须保持一致性， DBMS 还必须协调多用户的并行更新，以确保用户和他们的更改不至于影响其他用户的作业。 用于修改数据库内容的 SQL 语句主要有以下三个： 1、Insert，向一个表中加入新的数据行 2、Delete，从一个表中删除数据行 3、Update，更改数据库中已经存在的数据 首先我们来看看 Insert 的用法： 标准语法： INSERT INTO table_name (col1, col2...) VALUES(value1, value2...) 下例要将书生作为一个新的销售员加入表 Salesreps 中 Insert Into Salesreps (name,num,sales,hire_date,income) values ('shusheng',9,10000,'23-Feb-99',) 在此语句中，列的名称列在括号中以逗号隔开，接下去是 Value 短语和括号中同样以逗号隔开的每列数据，应该注意的是数据和列名称的顺序是相同的，而且若是字符串型则以单引号隔开。从概念上来讲， Insert 语句建立的一个与表列结构相一致的数据行，用取自 Values 子句的数据来填充它，然后将该新行加入表中，表中的行是不排序的，因此不存在将该行插入到表的头或尾或两行之间的这个概念。 Insert 语句结束后，新行就是表的一部分了。 Insert 语句还可以将多行数据添加到目标表中去，在这种形式的 Insert 语句中，新行的数据值不是在语句正文中明确地指定的，而是语句中指定的一个数据库查询。添加的值来自数据库自身的行，这乍看起来似乎有些奇怪，但是在某些特定的状态下，这是非常有用的， 比如，你想把 年 12 月 30 日之前产生的订单编号、日期和数目从 order 表中拷贝到另一个名为 oldorder 的表中去，多行 Insert 语句为拷贝数据提供了一种紧凑而高效的方法，如下： Insert into oldorder (Num,Date,Amount) Select Num,Date,Amount From order Where Date<'30-12-98' 这条语句看起来有些复杂，其实很简单，语句标识了接收新行的表 oldorder 和接收数据的列，完全类似于单行 Insert 语句。语句的剩余部分是一个查询，它检索 order 表中的数据。 SQL 先执行对 order 表的查询，然后将查询结果逐行插入到 oldorder 表中去。 下面我们来看看 Update 的用法， Update 语句用于更新单表中选定行的一列或多列的值。要更新的目标表在语句中定义， Set 子句则指定要更新哪些列并计算他们的值。 Update 语句总是包含 Where 语句，而且 Update 语句比较危险，所以您必须明确地认识到 Where 语句的重要性， Where 语句被用来指定需要更新的行。 标准语法： UPDATE table_name SET columnname1 = value1 [, columname2 = value2]... WHERE search_condition 以下是一个简单的 Update 语句的例子 : Update customers Set credit=100000.00,id=99 Where name='asp' 在此例中我们将表 customers 中客户名为 asp 的客户的信贷值更新为 10 万并将他的 ID 变更为 99。再看下例： Update customers Set credit=200000.00,state=021 Where ID in (80,90,100,120) 我们可以发现，其实 SQL 处理 Update 语句的过程就是逐行遍历所指定的表，更新其搜索条件结果为“真”的行，跳过其搜索条件结果为“假”或“空”的行。 最后，来看看 Delete 语句。 标准语法： DELETE FROM tablename WHERE condition 由于它过于简单，所以所造成的后果也是严重的，虽然其中的 Where 子句是任选的，但它几乎总是存在的，若将 Where 子句从 Delete 语句中省略掉，则目标表的所有行都将被删除。看下例： Delete from order Where ID=99 在文章的末尾，作者在给大家简要介绍一下数据定义语言。它是用来创建和修改数据库结构的一种语句，包括 Create 和 Drop 语句。 1、Create 语句 标准语法： CREATE TABLE table_name ( field1 datatype [ NOT NULL ], field2 datatype [ NOT NULL ], field3 datatype [ NOT NULL ]...) 如： CREATE TABLE BILLS ( NAME CHAR(30), AMOUNT NUMBER, ACCOUNT_ID NUMBER) 尽管 Create Table 比前面介绍的语句难理解一些，但仍然很直观。它将 bills 赋予一个新表，并指定表中三列的名称和数据类型。表被建立后我们就可以添入数据了。如： Insert into bills(name,amout,account_id) values('gates',100,1) 如果，你觉得不再需要保存产品信息，则可用 Drop table 语句将该表及其所包含的所有数据从数据库中删除掉。 标准语法： DROP TABLE table_name 关键词：实现 动态查询 PowerBuilder 中图分类号：TP311.132 文献标识码：A 0 引言 PowerBuilder是现今最为流行的数据库前端开发工具。掌握PowerBuilder开发工具固然重要，但运用开发工具开发一个有效的、易维护的、易升级的、功能强大的管理系统尤为重要。本文利用PowerBuilder开发工具应用在汽配管理系统为例，探讨了汽配管理系统的制作方法，着重研究了动态查询在汽配管理系统中的实现方式，延伸了Powerbuilder开发工具实用性。 1 汽配管理系统的系统分析 本系统是面向汽车配件销售管理的管理信息系统。该系统能对汽车配件行业进行进货、销售、存储的有效管理，且能集中管理汽车配件的应收应付帐，并能实现查询分析统计等功能，及时响应企业汽车配件进销的快速查询和分析，使企业经营运作物流清晰，经营状况一目了然。汽配管理系统数据表结构及表间关系详见图1。 2 动态查询的实现 在PowerBuilder中，动态查询的实现归根结底就是在应用程序中完成一个Datawindow的制作，而可通过SQL语句的转换得来[1]。因此，如何生成SQL语句就成了问题的关键。 分析SQL的SELECT语句： Select’数据表’.’字段名’from’数据表’ ……………第一部分 Where’表间关联条件’and’查询条件’ ………………第二部分 从上述分析可以看出:SQL语句是有数据表及其字段、Where子句与表间关联等几部分组成的。寻找和利用其特点，就有可能实现动态查询。 2.1 数据表及字段的选择 数据表及字段的选择是指选择数据库中具体的数据表及所需查询的表字段，完成SQL语句的第一部分制作。在汽配管理系统中，供用户查询的数据表有8个，其中每个数据表拥有多个字段。为方便用户的选择，采用列表选择的方法，分别用两个列表显示数据表及其字段。当用户通过第一个列表选择数据表时，在第二个列表中显示出第一个列表所选择的数据表的所有字段。在第二个列表中，双击所需的字段名。这样的操作就选定了数据表及字段。实现上述选择的关键是：在汽配管理系统中的动态查询模块里，定义了两个字符型实例变量：LS-database[ ]及LS-field，分别容纳所选定的数据表名及字段名字符串[2]。在字段列表框双击事件中，又定义了两个字符型局部变量：Se-database及Se-field分别容纳双击后选定的数据表名和字段名。其实现流程图详见图2。 从图2可知，数组LS-database[ ]及LS-field中存储的内容，便是选定的数据表和字段名。 2.2 WHERE子句的生成 SQL语句的第二部分是Where子句。该子句是SQL语句的一个关键部分，用户正是通过它来满足检索的要求。Where子句是有逻辑关系符、检索字段名、检索操作符及检索值组成。其中逻辑关系符是指在Where子句间的“或者”和“并且”的关系。检索字段名是指用户提出检索要求的字段名。检索值是指对检索字段提出的要求。检索操作符是指检索字段与检索值之间的关系。Where子句的四个组成部分分别由三个下拉列表和一个单行编辑构成，其中检索字段下拉列表项由数据表及字段选择中选择出来的字段名组成。Where子句实现思路：通过循环算法，把多个Where子句的四个组成部分组合起来，形成条件查询子句。 2.3 数据表间的关联 在前两节的基础上即可顺利地选择出与字段，并生成Where子句及SQL语句。这时，制作并未完成。因为数据表间关联这个关键部分还没有解决。在Datawindow的人机交互制作过程中，表间关联可自动生成。但在应用程序里，生成Datawindow的过程必须通过应用程序设计编制才能实现[3]。表间关联的基本思路是：在PowerBuilder的数据库中，表间的关联是固定的，表与表之间的关联情况可以看成为一个二维表的关系。因此，在系统中设计了关系表查询方案，以解决数据表间的关联问题。所谓关系表，是指一个能反映任意两个表相联关系的二维表格。若两个表相关联，则在二维表格交叉栏内填入关联字段。若两个表不关联，则在二维表格交叉栏内填入空格。建立好关系表后，根据在数据表与表字段选择中所选择的数据表名（存储在数组LS-database[ ]中），在关系表中，两两查询关系。若两表关联，根据交叉项中所得的关系在Where子句中填入相应的语句即可完成。 2.4 Datawindow的生成 在表间关联子句生成后，SQL语句的制作便完成了。但如何将SQL语句转换成Datawindow呢？这里需要引进两个函数：SyntaxfromSQL()和Create(): 函数SyntaxfromSQL()用于产生一个Datawindow，它拥有三个参数:第一个参数是用于传递SQL语句（即在2.2中所生成的SQL语句）；第二个参数用来表示Datawindow的风格；第三个参数是在Datawindow生成过程中出错时保存错误信息。 函数Create()，使用从函数SyntaxfromSQL()中返回的属性信息，在运行状态下建立一个Datawindow。它有两个参数：第一个参数即是从SyntaxfromSQL()函数中返回的字符串变量。第二个参数用在出错时存储出错信息。 在系统中的具体实现代码如下： String sq1-statement，present，error，answer SQL-statement=…… //SQL-statement中存储着SQL描述语句 Present =”Style(type=grid)” // Present 中存储着Datawindow风格等属性 answer=sqlca. SyntaxfromSQL()(SQL- statement, present,error)//产生Datawindow Dw-1. Create(answer, error)//建立Datawindow 至此完成了动态查询的全部制作，实现了在PowerBuilder中动态查询。 3 结束语 通过以上建立的对数据表及字段的选择，把多个Where子句的四个组成部分组合起来表与表之间的关联看成了一个二维表的关系，运用函数SyntaxfromSQL()和函数Create()生成Datawindow，实现了在PowerBuilder中动态查询。 参考文献： [1]崔巍.PowerBuilder8.0数据库应用系统开发教程[M].北京:清华大学出版社.2003.1:105-109. [2]何军.PowerScript语言·事件·函数[M].北京:电子工业出版社.2003.6:255-258. 1 查询优化的必要性 查询优化对系统性能的提高起到非常重要的作用。有些程序程序设计员觉得查询优化只是DBMS的任务, 而与所编写的SQL查询语句没太大关系, 这种想法是不对的。由于SQL语句是操作数据库唯一的途径, 所有应用程序的执行最后都是要归结到SQL语句的执行, SQL语句的运行效率将直接决定数据库系统的性能。所以查询语句的优化是查询效率提高的根本。下面通过一个例子说明进行查询优化的必要性。 例:查询到选修了课程号为3的课程的学生姓名。用SQL语句来表达如下: 假设在该数据库中拥有1000条学生的记录, 10000条选课的记录., 而其中选修了3号课程选课的记录是50条。 系统能够运用多种相互等价的关系表达式来进行查询: 除了这三种表达式之外还有几种, 但本文就仅引用这三种来进行对比分析。我们将会看出因为查询所执行策略的不同, 其查询的效率也将相差的很大。 1) 对于第一种情况 (1) 首先计算广义的迪卡尔积 将Student与KC的每个元组进行连接。通常采用的连接方法是:在内存里尽量多的装进某一个表 (如KC表) 的若干块元组, 而留下一块用来存放另外一个表 (如Student表) 的元组。紧接着将Student中的每一个元组与KC中每一个元组进行连接, 在连接之后的元组将一块装满后就将其写到中间文件里, 然后再从Student里读取一块与内存中的KC元组进行连接, 直至Student表全部处理完。这个时候再次读取若干块KC的元组, 读取一块Student的元组, 然后重复以上的处理过程, 直至将KC表中内容全部处理。假设每个块能够装10个Student元组或者100个KC的元组, 那么在内存里放入5块KC元组以及1块Student元组, 则读取总块数为: 其中读了Student表的100块。KC表读了20次, 而每一次是100块。如果每秒读写量为20块, 那么总共要花105秒的时间。假设每块能够装入10个元组, 那么将这些块写出所要花的时间为103×l04=107秒。 (2) 进行选择操作 依次将连接后的元组进行读取, 根据选择的条件将达到要求的记录选取出来。如果忽略内存的处理时间。那么这一步中间文件的读取所花费的时间为5×l04秒。 (3) 作投影处理 将第二步的结果在Name进行投影输出, 得出最后的结果。所以该情况下所执行的查询总时间大约为105秒。 2) 对于第二种情况 (1) 首先计算自然连接 为了能够执行自然连接, 对KC与Student表的读取策略保持不变, 所需总的读取时间任为105秒。但是自然连接的结果却比第一种的情况很大程度上减少了, 大约104条。所以将这些元组写出的时间大约为50秒。所化时间仅是第一种情况所用时间的千分之一。 (2) 然后读取中间的文件块, 进行选择的运算, 所花费的时间也50秒。 (3) 将第二步的结果进行投影输出。那么第二种情况所用的总时间大约为205秒。 3) 对于第三种情况 (1) 首先对KC表进行选择的运算, 只对其进行一次读操作, 而存取100块所花费的时间是5秒, 这是因为达到条件的元组只有50个, 没有必要用到中间文件。 (2) 读取Student表, 将读取的Student表的元组以及内存里的KC表的元组进行连接。这里只需要读取一次Student表, 总共花费的时间是5秒。 (3) 最后将连接的结果进行投影输出。那么第三种情况所花费的总时间大约为10秒。 通过以上这个比较简单的例子能够充分的说明进行查询优化的必要性, 也让我们对于查询优化的一些方法有了比较初步的了解。例如当同时存在选择与连接操作的时候, 应该先进行选择的操作, 这样进行连接的元组就能够在很大程度上减少了。 2 常用的查询优化方法 首先简单介绍一些比较常见的查询优化方法, 其次重点介绍通过合理安排索引来进行查询优化的方法。 1) 比较常用的查询优化的方法有: (1) 将选择运算算与投影运同时进行。 倘若在同一关系中存在多个选择与投影的运算, 那么可将选择的运算与投影的运算进行结合, 此举目的在于选取出满足条件的元组之后就对其进行投影操作。 (2) 选择的运算应量先进行。 由于符合选择的条件的元组通常情况下都是原来关系的子集, 这就让计算的中间结果变小了。这种做法是最为基本也是非常有效的查询优化方法。 (3) 将一些选择与其之前执行的笛卡尔积进行结合形成一个连接的运算。 连接尤其是等连接的运算与同样关系上的笛卡尔所积产生的结果相比要小很多。所执行的代价也小很多。 (4) 将投影与其前后的双目运算进行结合。 双目运算主要包括JOIN运算与笛卡尔积, 同以上几条方法原理类似, 当进行JOIN运算或笛卡尔积的时候, 都要将关系的元组选出, 没必要为了投影操作而将关系单独的扫描一次。 (5) 恰当的选择连接的算法。 连接的操作在关系操作中是最为费时的操作, 如今也有了许多进行连接优化的算法。例如排序合并算法、索引连接算法以及HASH连接算法等。恰当的选择连接算法从一定意义上说是存取路径的选择, 属于物理优化的范畴。一些RDBMS已经提供了多种的连接算法来为优化子系统服务。 2) 合理的安排索引的方法 索引是由用户来定义的, 存储与物理介质中的数据结构。当按照索引来进行数据查询的时候, 索引就提供了对数据快速的访问。倘若不依靠索引, 数据库也可以依靠SELECT语句查询到相应结果, 但是随着记录数量的不断增加, 运用适当的索引能够让查询效率在很大程度上提高。然而, 倘若在对索引的使用过程中, 不能够认真的考虑索引实现的过程, 那么将会造成数据库性能的破坏。 索引的创建通常有两个目的:一是对被索引列的唯一性进行维护;二是提供对表中数据进行快速访问的策略。一般大型的数据库拥有两种索引方式:聚集索引与非聚集索引。其中, 聚集索引是数据行的键值为基础在表内进行排序以及数据行的存储, 这就是根据索引列对表进行物理的排序, 所以在一个表里只可以存在一个聚集索引。如果表中没有聚集索引, 那么数据则按堆集的方式进行存储。采用聚集索引进行的数据查询的效率最高, 尤其对于那些需要频繁搜索的列非常的有效。而非聚集索引的结构是完全的独立于行的, 它不对表中的数据进行排序, 所以在一个表内可创建几个非聚集的索引。由于非聚集索引的键值项是通过指针指向包含此键值的数据行的, 因此其查询的效率要比聚簇索引慢些。对于索引文件的安排可从如下几点考虑: (1) 当表中对主键的查询较少并且很少按范围检索的时候, 此时不要将聚集索引建立于主键上。因为每一张表只有一个聚集索引, 应该根据实际的应用情况确定将其分配给经常使用范围检索的属性列, 这种做法可以最大限度地提高系统的运行效率。 (2) 对于索引较多的表, 如果进行频繁的插入、更新、删除等的操作, 在建表和设置索引时应当尽量设置较小的填充因子, 以在各个数据页中留下比较多的自由空间, 以此来减少页分割和重新组织的工作。 (3) 当用户检索的数据量较大时, 则必须在相应的数据列上建立索引、同时建立复合索引时涉及的属性列应尽量控制个数, 不要太多, 否则将会增加索引的开销。当执行更新操作时, 数据库的更新速度会降低。 (4) 当检索的属性列中其记录值重复非常多, 如逻辑型的数据、标志位, 那么在这样的属性列上不需建立索引。 (5) 如果要频繁修改索引列的值、则避免在该属性列上建立聚簇索引, 这种操作会降低系统整体的运行效率。 (6) 越窄的索引具有越高的效率。对于比较窄的索引, 每页可以存放较多的索引行, 且索引的深度较少。因此, 缓存中可以存放更多的索引页, 这样也就减少了输入输出操作。 (7) 索引不是建立得越多越好。当对表执行更新时, 系统此时会自动更新该表的所有索引文件, 而索引文件的更新是需要耗费时间的, 这样也就降低了系统的运行效率。 (8) 设置合理的组合索引。查询时, 在查询条件中必须使用组合索引前导列, 否则该组合索引失效。如果在SQL中形成了索引覆盖的情况, 性能将达到最优。 3 结束语 合理的选择查询优化的方法能够很大程度上增加系统的查询效率, 从而提高了整个系统的运行效率。现如今, 在查询优化方面的研究也越来越多, 其研究的价值也是有目共睹的。因此, 无论从哪方面来说, 进行查询的优化方法的研究都是有意义的。 摘要：运用数据库查询优化技术能够让一般的查询效率在一定程度上得到提高。该文首先通过举例说明优化查询的必要性, 并在此基础上提出查询优化的方法。 关键词：数据库,查询优化,查询效率 参考文献 [1]蒋本立.数据库原理及应用[M].北京:中国铁道出版社, 2006. [2]黄德才.数据库原理及其应用教程[M].北京:科学出版社, 2006:103-104. [3]尹萍.SQLServer数据库性能优化[J].计算机应用与软件, 2005, 22 (3) . 随着信息技术的不断发展, 计算机技术在各个领域的应用也不断成熟, 相应的各种应用软件的不断普及, 应用数据也随着日常工作而迅速增长, 作为管理大量数据信息的数据库其重要性也日益突出。基于数据量的增大, 数据查询的效率需要优化与提高。本文主要研究数据库的数据查询优化问题, 对优化技术进行分析与研究。 一、数据库的概念与特性 数据库系统是物理上分散而逻辑上集中的数据库系统。该系统可以将存放分散的数据通过计算机网络进行集中的管理, 组成完整的数据库管理系统。分布式数据系统有机的结合了计算机网络的信息传输功能, 具备以下主要特性: 1、数据的分散存储性: 分布式的数据库系统中数据以节点的方式分散存储在不同的站点下, 区别于集中管理的数据库数据, 具有分散性和关联性。 2、数据的逻辑整体性: 数据分散存放的过程中与其他数据之间具有逻辑关联, 建立远程关系形成整体, 做到数据存放分散但具有逻辑整体性。 3、数据的独立性: 存放数据库网络站点的施数据各自独立, 登录用户可以实现信息共享, 却自成一体进行局部管理。 二、数据库查询优化策略研究 当前数据库查询以关系型数据存储为基础, 对数据建立索引, 采用SQL作为检索查询工具, 可从硬件设备与查询策略上进行查询的优化和改进。 1、硬件优化 提高服务器性能, 升级计算机硬件配置。由于数据的访问量大, 访问内存数据的需求相对提高, 增大内存可以将缓冲区中的数据量增多, 减少磁盘的供耗时间, 提高数据访问效率;设置多处理器进行数据库管理, 对多事务实现并行;配置高转速硬盘减少数据读取时间, 提高读取速度。增大服务器的内存高速缓冲区, 其大小由缓冲区的命中率决定, 数值越高, 性能越好。 2、查询策略优化 (1) 查询的层次结构优化 查询策略是将客户端提交的查询请求转换为本地可执行的查询语句, 对多节点的查询结果进行汇总。将其结构分为四个层次:查询解析、数据本地转换、数据全局优化、数据节点优化。 (1) 查询解析:将整体查询请求进行分析, 转换为全局查询树从而得到段查询树。 (2) 数据本地转换:将查询树中的命令进行本地化转换, 对当前节点数据库中的数据进行访问。 (3) 数据全局优化:对分段检测查询选择最优查询顺序, 将通信代价降低至最低, 优化关系数据的统计, 得到整体的统计数据。 (4) 数据节点优化:对本地数据库中的数据进行优化存储, 采用集中式数据库的优化算法进行关系运算。 (2) 等价关系代数优化 基于关系代数的优化方法:数据库查询操作的基础就是关系运算, 所以利用关系代数变换来实现查询优化是目前最常见的。其主要原理就是通过关系代数的等价变换, 从而减少查询中的计算量, 进而实现查询的优化。主要原则就是在关系运算中尽量避免直接执行运算量较大的笛卡儿积运算, 而采用先执行关系代数表达式中的选择和投影操作, 后把笛卡儿积操作之前和之后的一连串选择和投影合并起来一起做。这样就能减小运算量。该方法主要用于删除无用数据, 从而减小运算, 主要作为预处理使用。 (3) 建立合理的索引 索引是数据库不可缺少的重要部分。一般情况下利用索引在数据库内进行数据查询, 索引能够对所查询的数据进行快速访问, 无需对整个表进行扫描, 大大减少了数据库查询的响应时间。然而, 随着查询次数的增多, 数据库中对查询的记录次数也随之增多。所以, 合理适当的运用索引可以大大提高数据查询效率。然而, 在适用索引进行数据查询时存在一些问题, 如索引会占用一定的存储空间;对数据库进行更新时, 索引也要进行更新, 增加了一些不必要的开支。 (4) 查询语句优化 数据库, 采用全局查询处理, 分两步进行。即全局查询到逻辑查询的转换以及逻辑查询到物理查询的转换。查询语句独立于程序设计逻辑, 相对于程序源代码的优化, 查询语句优化能够有效的降低查询处理的时间, 风险和时间成本更低, 因而查询语句的优化具有重要意义。 数据库查询策略主要分图的查询优化和树的查询优化两类。图的查询优化作为最常用的查询策略, 主要依据关系的静态属性进行连接计算, 连接合并图中代价最小的两个站点, 形成检索算法。树的查询优化原理是生成一棵最小代价查询树, 以此缩短查询时间。 三、查询优化目标和代价 基于直接连接查询的优化方法:该方法的着眼点在于连接, 通过研究关系的静态属性来构建一个最好的处理策略和连接顺序。在分布式数据库中, 主要采用的优化策略为: 1、利用站点依赖信息来实现。 就是在关系进行连接运算时, 首先将同一站点上的子片段进行连接, 然后再传输到目标站点上进行合并。该方法的主要优势是站点间无数据传送代价, 并可利用本地索引信息加速连接。 2、是分片和复制算法。 该方法就是将查询需要的关系的片段分配到选定的站点上, 然后将其它关系进行复制, 目的是让选定的站点上都搬出完整的关注, 第三步就是在各站点上进行直接连接操作, 最好将结合传到目的站点, 该方法的主要优势是响应时间更短, 但存在数据冗余的缺点。 3、是站点依赖和数据复制结合。 该方法结合站点依赖信息和数据复制信息, 减少关系片段的复制, 使特定查询能以无数据传输的方式进行, 从而缩短响应时间。最后一种方法是采用Hash划分策略。该方法采用Hash函数将关系根据连接属性进行片段划分, 使得连接的两个关系之间满足站点依赖, 以根据站点依赖方法进行连接查询。基于直接连接查询的优化方法由于传输代价太大, 所以只适合于查询处理慢, 传输快的高速局域网场合。 结语 在大型数据库广泛应用的时代, 数据库查询优化已成为一门关键技术, 运用合理, 可以大幅提升数据库系统的效率。提升硬件方面的优化是要衡量开销的, 使用优化器等软件优化仅是常规的优化, 在实际的应用中, 最需要关注和探索的是发掘现有服务器的潜能, 对数据查询方案作有效的分析并整理出高效率的数据查询方案。 摘要：结合当前数据库技术的发展, 从查询的层次结构、等价关系代数、索引、查询语句等方面对数据库查询优化进行了研究。探讨了在数据库应用方面的一些查询优化策略, 其中包括基于索引、SQL语句书写方面的优化方法, 并对其他一些常用方法做了简要介绍。 关键词：数据库,查询优化,索引 参考文献 近年来, 随着计算机网络和数据库技术的发展, 对分布式数据库的应用越来越广泛;随着应用不断扩大, 数据的查询也越来越复杂, 对查询的效率要求也越来越高, 因此查询处理成为分布式数据库系统中的一个关键性的问题[1]。在分布式数据库中, 由于数据的分布与冗余, 使得查询处理中一般需要站点间的数据传递及通信费用, 成为查询优化的主要矛盾;另一方面, 数据的分布与冗余也增加了查询的并发处理的可能性, 从而可以缩短查询处理的响应时间, 提高处理速度。总之, 分布式查询的规模与优化的因素, 都与集中式查询优化不同, 因此许多数据库专家学者致力于研究分布式数据库查询优化技术这一重要课题, 并且己经在这一领域作了大量的工作, 也找到了规律, 包括一些大家公认的经典算法;然而由于分布式数据库本身的灵活性, 要想设计一个算法对于各种情况都是最优的几乎不太现实, 只能说设计一个较优的优化算法, 它可以解决某一类型的问题[2]。分布式数据库中查询优化是一项复杂问题, 已经被证明属于NP完全问题, 至今都没有得到彻底地解决, 里面尚有许多问题值得研究和探讨。 1 分布式查询优化的目标 分布式数据库系统的查询优化有两种不同的目标:一种目标, 是以总代价最小为标准;另一种目标, 是以查询响应时间最短为标准, 这一点在分布式数据库系统中具有重要的意义。因为分布式数据库系统是由多台计算机组成的系统, 数据的分布和冗余也增加了查询的并行处理的可能性, 从而可以缩减查询处理的响应时间, 加快查询处理速度。在分布式查询优化中也常同时使用这两种标准, 根据系统应用的不同, 一种作为主要标准, 另一种作为辅助标准[3]。在分布式数据库系统中, 查询优化包括两个内容:查询策略优化和局部处理优化, 而查询策略优化尤为重要。分布式查询策略的优劣将直接影响计算机网络资源耗费的多少。 在集中式数据库系统中, 查询优化的目的可以总结为以下三个方面: 1) 为每个用户查询寻求总代价最小的执行策略; 2) 总代价是以查询处理期间的CPU代价和I/O代价来衡量的; 3) 总代价最小就意味着查询的响应时间最短。 从上可看出, 在集中式数据库系统中, 一个查询策略的选择是以执行查询的预期代价为依据的。由于系统大都运行在单个处理器的计算机上, 所以查询执行总代价为CPU代价加I/O代价[4]。而在分布式数据库系统中, 由于数据的分布在多个不同的站点上, 使得查询处理中需要考虑站点间传输数据的通信费用, 所以除了考虑CPU代价和I/O代价之外, 还应该包括数据在网络上的传输代价。所以在分布式数据库系统中, 常以两种不同的目标来考虑查询优化:以总代价最小为标准和以每个查询的响应时间最短为标准。这样分布式查询优化可用以下四个参数来衡量: 1) CPU代价, 即占用的CPU处理周期, 记做Ccpu; 2) I/O代价, 记做Ci/o; 3) 通信代价, 记做Cmsg; 4) 传输的数据代价, 记做Cbt。 2 分布式查询优化的基本方法 在分布式查询处理技术中, 查询优化有两种基本方法:第一, 是查询转化, 即以不同的顺序执行关系操作, 如连接和投影操作:第二, 是查询映射, 即使用一系列高效的算法来存取各种设备和实现关系操作。查询转化是指关系运算集合运算顺序的改变, 对查询的性能有重要影响[5]。在多站点下, 查询转化可以减少通信量, 从而达到减少查询代价的目的[6]。查询映射则是针对关系的存取方法和操作的执行算法进行决策。 2.1 查询转化的处理过程 查询转化处理一般经历三个阶段: 1) 建立关系代数表达式。根据查询问题, 编写关系代数表达式。 2) 建立查询语法树。根据关系代数表达式, 生成查询语法树。 3) 全局优化。按照优化策略, 对查询语法树进行全局优化。 优化策略:查询优化策略按以下步骤进行: 1) 将关系代数表达式转换成选择串接形式。 2) 尽可能把选择和投影操作移近树的叶端, 即尽可能早地执行选择和投影策略, 以得到较小的中间关系, 减少运算量。 3) 把选择和投影合并成单个选择、单个投影或一个选择后跟一个投影。使多个选择和投影能同时执行或在一次扫描中同时完成。 4) 将上述步骤得到的查询语法树的内结点分组。每个二元运算结点与其直接祖先的一元结点分为一组。如果它的子孙结点一直到叶结点都是一元运算符, 则并入该组。 5) 生成一个程序, 每一组结点的计算是程序中的一步, 各步的顺序是任意的, 只要保证任何一组不会在它的子孙组之前计算。 2.2 查询优化的三种典型算法 2.2.1 INGRES算法 INGRES算法是动态的优化算法。这个算法主要分为两个步骤: (1) 将含有多个变量的查询分解为一系列的只含有一个变量的单关系查询。 (2) 通过执行其每一个单关系查询:用启发式的方法选择一个初始化的执行计划, 通过中间关系的大小来确定查询执行的顺序。 首先来看分解的详细过程:用一系列的单关系查询qi取代n个变量的查询q, 就比如:q1->q2->…->qn, 其中qi使用qi-1的执行结果。 它主要有两个基本的动作:分离与元组替换。 分离:查询q分解成q’和q’’, 当q’和q’’有一个共同的量在q’的结果里。 查询分解算法: 元组替换:用元组的实际值来替换并且简化查询, q (R1, R2, …Rn) 被{q’ (t1i, R2, …, Rn) , t1i∈R1} 2.2.2 System R*算法 System R*算法是源于美国CA州的IBN San Jose Research Laboratory开发System R*系统, System R*系统是采用直接连接作为查询处理策略的分布式数据库系统, 其最重要的目标是提供地点自主权。当每个地点既能控制由另一个地点上对其数据的访问, 也能在不受任何其它地点限制的条件下处理自己的数据时, 也就实现了地点自主权。R*系统完全实现了第一个目标。但它仅仅是部分地实现了第二个目标。 R*系统由3个主要部分组成:局部DBMS、提供信息传输的数据通信部分和能协调实现多地点事务处理的事务处理管理程序。局部DBMS可分为两个部分:存储系统 (用于数据的存储与检索) 和数据库语言处理器 (用于将高级SQL语句转换成存储系统上适用的操作命令) 。R*方案中采用的存储系统叫RSS*, 是以系统R的存储系统为基础。R*各地点通过CICS的系统间通信 (ISC) 设备进行通信。每一个R*地点都在一个CICS地址空间运行, 而CICS控制终端I/O和信息通信。假定该通信是不可靠的 (不能保证所传输的信息总能送到) , 但可以假定所送到的信息是正确的、不重复的, 并以与发送它们的相同次序接收。一个应用程序在其局部地点执行所有对R*系统的数据库访问请求。所有地点间的通信均在不同地点的R*系统之间进行。因为是R*、而不是应用程序负责为分布式数据定位。这样, 在R*环境中不需要远程应用程序。应用地点的事务处理管理程序, 把未包括在明确定义的事务处理中的第一个SQL语句看作是事务处理的开始, 隐含地执行一个开始一一事务处理。当用户完成一次会话后, 就假定一个隐含的结束一一事务处理, 并提交所有已经完成的工作。 R*系统的另一个重要问题是位置透明性 (用户并不知道数据的实际位置) 。这样, 从程序员的观点来看, 使用R*系统与使用集中式系统基本一样。虽然在R*系统中引入的附加语言特性极少, 但R*系统的主要成就是在分布式环境中提供了SQL/DS的大多数功能。在R*系统中, SQL查询既可以静态地进行编译 (n个执行编译一次) , 也可以动态地进行编译 (在单个执行前立即进行编译) 。前一种情况用于重复查询;后一种情况用于预先不知道的查询。在R方案中, 重复查询的重要性比预先不知道的查询高得多。在这两种情况下, 非过程型SQL语句被转换成访问计划, 该计划规定访问关系的次序进行访问的地点, 完成每一个操作的方法及在RSS*中检索或处理元组的访问路由。 2.2.3 SDD-1算法 SDD-1算法由两部分组成:基本算法和后优化。基本算法是根据评估所缩减程序的费用, 效率, 收益估算等几个因素, 给出全部的半连接缩减程序集, 决定一个最有益的执行策略, 但效率不一定理想。主要包括三个基本步骤: (1) 初始化:已准备好从查询数转换的优化模型, 且所有关系已完成局部缩减。 (2) 优化:根据初始条件, 构造可能的半连接缩减程序;按半连接缩减程序的静态特性表, 分别计算其代价和产生的益处, 从其中选取一个半连接程序, 设为S;以S完成缩减以后, 又用重新产生的一组新的静态特性表再进行计算, 再从其中选取一个合适的半连接程序, 但每一个都只做一次;循环下去, 直到没有半连接缩减程序为止。 (3) 结束:以最后一次缩减关系的静态特性表为基础, 进行费用计算, 选择场地。后优化是将基本算法得到的解进行修正, 已得到更合理的执行策略。包括两种修正:一种, 是如果最后一次半连接程序缩减关系的所在场地恰好是被选中的执行场地, 则最后一次半连接可以取消;另一种, 修正是在基本算法的流程图进行修正, 因为某一个半连接缩减程序的代价可能很高, 就必须修正半连接的操作序。 SDD-l算法: SDD-1算法支持关系数据模型。全局关系能以两个步骤分段 (首先水平分段, 然后垂直分段) , 能以冗余方式存储各段。SDD-1能提供段存储透明性 (用户不知道段和段的分配) 利用数据语言, 即适用于数据计算机的高级过程语言实现关系控制。 SDD-1算法的体系结构是基于三个相对独立的虚拟机:数据模块、事务处理模块和可靠的网络。这种体系结构允许把分布式数据库管理问题分成三个系统, 以限制相互的影响。 SDD-1算法存在一个严重问题, 那就是它的算法的复杂性。当元组数目很大时, 进行查询搜索的代价进迅速增加, 使系统无法承受。当然, 对于这种搜索模式, 可以找到最佳的路经去进行查询。为此, 我们在此基础上对它进行改进, 降低它的时间复杂度。在人工智能里面的A*算法可以引入到SDD-1算法中来, 当元组数目不是很大时, 可以采用A’算法的思想对它进行查询优化, 在此基础上能找到最优的方法去进行路径搜索和优化, 而当元组数目非常多的时候, 还是用以前的方法。 3 结束语 分布式数据库系统的查询处理是用户与分布式数据库系统的接口, 查询处理策略的好坏直接影响到系统的执行速度。本文通过实例重点讨论了在分布式数据库系统中应用优化策略, 减少运算数据量和网络资源的耗费, 提高了查询效率。至于对于给定的查询, 应该怎样选择好的查询策略, 进行分布式查询优化, 我们可以根据已有的优化算法和分析各种查询策略的特点来选择一个较好的查询策略。 摘要：本文介绍分布式数据库系统查询优化的目标、策略, 着重讨论了一种分布式数据库系统查询优化策略是如何影响查询的, 并对分布式数据库系统的查询优化的典型方法进行了分析、总结。分布式数据库系统由于数据的分布和冗余使得分布式查询处理增加了许多新的内容和复杂性, 对于一个给定的查询, 通常会有多种可能的策略, 查询优化就是从这许多策略中找出最有效查询计划的一种处理过程。并针对分布式数据库系统的查询优化, 讨论了三个典型的算法:INGRES算法、SystemR*算法、SDD-1算法。 关键词：分布式数据库,分布式查询,查询优化,查询处理策略,算法 参考文献 [1]徐俊刚, 邵佩英.分布式数据库系统及其应用[M].北京:科学出版社, 2012, 4. [2]申德荣, 于戈.分布式数据库系统原理与应用[M].北京:机械工业出版社, 2011, 8. [3]王丽艳, 郑先锋, 刘亮.分布式数据库系统及其应用[M].北京:机械工业出版社, 2013, 2. [4]吴溥峰, 张玉清.数据库安全综述[J].计算机工程, 2006, 32 (12) . [5]O’NeilP, O’NeilE.数据库原理、编程与性能[M].北京:机械工业出版社, 2002. 现在的主流并行数据库都是基于无共享架构, 在制定查询计划阶段, 是采用完全相同的模式, 不同之处是查询优化的策略和路径生成过程中所考虑的代价模型不相同。在制定好查询计划后, coordinator需要将查询计划发送给需要执行的节点进行查询的执行, 此时两种策略的执行方式不同, 但对结果的回收机制相同:各节点完成自身的查询计划后, 会将结果返回给coordinator进行最后的汇总。 通过分析, 发现根据查询计划的发送方式不同, 在制定查询计划时存在的问题:采用将SQL语句重写后发送的方式, 优点是各节点是一个独立的数据库在运行, 各节点接收到完整的SQL语句 (多条子语句) , 会遵循处理一条SQL语句的标准流程执行, 即对子SQL语句进行编译、优化和路径生成, 这样一来对单节点来说所制定出查询计划是最优的, 而coordinator上所制定的全局查询计划则会被改变, 即实际运行在各个节点上的查询相对于全局很可能不是最优的, 因为各节点无法知道全局节点的信息, 在制定本节点的查询计划时自然不会考虑与其他节点的通信代价, 即使考虑与其他节点的通信代价, 也无法将不与它通信的节点的通信代价考虑在内, 因此基于这个问题进行了调查。 2. 通信代价的分析 2.1 并行数据库的通信种类 在并行数据库系统下, 节点间通信包括以下三种情景:coordinator向各节点发送查询计划、各节点之间的join操作, 各节点向coordinator返回查询结果。 Coordinator向各节点发送查询计划和对结果的回收是在查询结果的执行前和查询结果的生成后, 这部分的通信对查询计划的优化没有任何影响, 因此通信的重点是如何优化join连接操作的通信代价。 在并行数据库系统下, 数据的存储策略主要包括Hash划分策略、Range划分策略以及round-bin (循环) 分区策略, 部分并行数据库系统支持局部划分策略。由于采用局部划分策略, 相当于在单节点的数据库上执行SQL命令, 没有并行因素, 与所研究的问题无关, 这里不做考虑。若采用Hash、Range和round-bin划分策略, 每个节点都存放数据表的一部分数据, 当并行执行时, 每个节点只对本节点上的数据进行操作, 当需要进行join操作时, 需要保证join操作的两个表中至少有一个是完整表, 而由于数据库本身的数据划分策略, 每个节点上的数据都不是完整的, 因此必须进行数据的迁移操作, 及各节点之间需建立通信并发送数据, 保证建立一个完整的数据表。 2.2 Join代价评估 在不同的参考文献和书中, 对join方法都各自的描述, 下面将这些方面描述如下:在并行数据系统下, 两节点的join操作通常包括两部分:发送端的代价和接受端的代价。 在一次通信过程中, 对数据的发送者既需要计算传输的启动代价也要计算数据的传输代价, 而对数据的接收者只需计算传输启动的代价。传输代价包括两个参数mp和ml, 它们参数都基于page level。mp表示启动报文传输的时间代价, ml表示报文传输的时间代价。 计算发送者的总代价的方法为: 为描述并行数据库系统的信息, [1]通过建立一个Libraries存储环境变量, 主要包括四种环境变量:Architecture Library数据库系统的硬件环境、System Library模拟操作和事物系统、Opetator and Access Method Library模拟算法、Data Base Profile Libaray管理数据库调度策略。将代价分为三部分:CPU时间代价、内存时间代价和网络通信时间代价, 并将网络代价的计算包含:发送包的时间 (Smt) 、接收包的时间 (Rmt) 和传输包的时间 (Ptt) , 但是并没有提出如何评估这些时间代价。[2]提出一种并行数据库系统下的代价估计模型, 将查询优化划分为两部分:the metrics和the libraries部分。在计算反应时间上定义了四种类型:local response time, effective time, distribution (partition) time, communication time, 其目的是根据并行数据库的分布策略, 在计算join操作时可能只计算几类反应时间, 本文这样分类的目的应该是对计算的细化。通过阅读以上的代表性的书籍和论文, 发现在并行数据库系统下, 将通信代价考虑在查询优化中已被多处提出, 但现有的开源数据库系统Gridsql和Postgres-xc都没有实现 (此点已被确认) ;但是现有文章都没有提出一个具体的通信代价计算模型, 论文中对这一部分的计算都是提出要考虑的变量, 打算做的工作就是提出一种数学模型计算各节点之间的通信代价。 3. 解决思路 对于问题一将SQL语句分解而无法计算通信时间的问题, 需要在coordinator节点上建立全局信息表, 全局信息表除了要包含并行架构下的硬件资源外还要记录当前运行事物的状态, 即每个事物开始和结束后都要向coordinator提交一个请求用来修改全局表中当前事物的运行状态。 结合问题一和问题二提出一种并行数据库系统下的优化方法, 该方法满足不论是将SQL语句分开发送还是以执行树的形式发送都适用。具体工作如下: (1) 建立一个全局信息表。该表主要包含3部分:全局硬件信息、全局网络构建、各节点状态信息。硬件信息用来估算各节点的处理延迟, 全局网络用来计算通信时的代价, 各节点状态信息用来描述当前系统中运行事物的状态。 (2) 选择概率统计模型。概率统计模型用来计算当处理多个写事物时, 写写之间发生冲突的概率。使用概率分布模型统计出在当前系统下, 发生n次写冲突的概率, 对于不同的冲突次数, 应该在coordinator节点上估计出处理这些冲突所需要的等待时间, 将这部等待的代价加入查询优化的代价估计中。 (3) 当发生冲突后, 根据步骤2中概率的大小, 和全局信息表中硬件信息估算出处理冲突的时间, 将这部时间加入到查询路径的生产阶段, 此部分的代价可能改变执行树的结构, 从而达到优化的效果。 4. 结论 本文通过分析并行数据库系统的查询优化的制订, 指出存在的弊端, 提出对应问题的解决方案, 为今后查询优化的制订提出技术支持。 参考文献 [1]F.Andrès et al.“A Multi-Environment Cost Evaluator for Parallel Database Systems”, 2nd Intl.Symp.on Database Systems for Advanced Applications, DASFAA’91, Tokyo, April 1991. 中图分类号：TP311.1文献标识码：A文章编号：1000-8136(2009)23-0015-03 1基本概念 1.1XML数据模型和XML数据模式 一个XML文档树是一个有序标签树(如果考虑元素之间的应用关系则以XML文档的基本结构为图)，每个节点与一个元素或值(文本)相对应，边表示元素和子元素(或值)之间的嵌套关系。XML文档的数据模式是一个有向图，它为XML数据提供完整性约束。 1.2XML数据的编码方法 到目前为止处理路径表达式查询有两种方法：一种是基于树遍历的方法，另一种不遍历文档树就可以快速决定节点之间结构关系的方法，元素之间结构关系的确定主要依赖于有效的XML节点编码方法。 1.2.1基于区域的编码方案 目前，最常用的编码方法是区域编码方法，最先使用区域编码确定树节点之间的结构关系的是Dietz。它给每个节点赋予一个(pre,post)编码，其中，pre是节点的前序遍历值，post是节点的后序遍历值，对于任意两个不同的节点x和y，x是y的一个祖先当且仅当x.pre 文献。给每个节点赋予一个(start,end)编码，一个节点的start和end值是该元素的开始和结尾的绝对物理或逻辑位移，如果一个节点的编码所覆盖的区域被另一个节点的编码所覆盖的区域完全包含，则这个节点是另一个节点的后代节点。为适用于多个文档查询和父子关系的确定，还可以将元素的编码扩展为(D，cid,start,end,levd)，Docid是文档的标识符，Level是节点在文档树中的层数。文献提出一种类似于区域编码方案——扩展的前序和后代范围编码，其目是的为了支持数据的动态插入和删除，每个节点被赋予一个(order，size)，order是节点的前序遍历序号。size表示节点所覆盖的范围，它可以是任意一个大于该节点后代节点总数的整数值。 除了区域编码以外还有另外一种相对区域编码方，每个节点被赋予一个到其父节点的相对位移。这种编码可以转换成区域编码，其主要缺点是为了确定节点的绝对位置查询代价沿着查询路径从祖先节点到被查询节点逐步增加。 1.2.2基于前缀的编码方法 不同于区域编码方法，基于前缀的编码方式保存路径信息。在这种编码方法中祖先后代关系和前缀子串的包含关系相对应。文献提出了K-ary编码，该方法通过增加虚节点把文档看成一个完全k分树，根据树的层次遍历顺序给树中的节点编码，在这种编码方法中节点的编码带有文档的结构信息。类似于K-ary编码，文献提出了一种特殊的PBiTree编码，这种编码方案是通过增加虚拟节点将文档树嵌入到一个完全二叉树中。这种编码的优点是可以利用完全二叉树的优良特性来计算节点间的结构关系。PBiTree中的虚拟节点起着—个占位符的作用，这样有利于数据的动态更新，同时它们对查询性能也有一定的影响。 1.3XML数据索引 为了提高查询的性能，许多专家和学者都致力于索引的研究与开发。目前提出的索引有两种：一种是基于结构连接的索引；另一种是基于路径的索引。基于结构连接的索引M首先将文档树中的所有节点以 2路径表达式的查询处理方式 2.1树遍历方法 最朴素的路径访问方法是树遍历的方法：一般采用自顶向下的方式遍历文档树，使用该方法进行查询时需要遍历某元素通往叶子节点的所有可能路径。为了减少树遍历的代价引入自底向上的方法，首先查找符合谓词条件的所有原子节点，然后再寻找它们的父节点。这种方法一般情况下比较简单、耗时较少。但对于符合谓词条件的节点数目很大而符合路径表达式的路径很少时，这种遍历方式的代价可能会高于自顶向下方式。一种折中的方法是同时按自顶向下和自底向上两种方法进行遍历，最后在路径的某个中间位置汇合，从而得到查询结果。当路径上某节点的扇人度(在文档中的)很大而符合谓词条件的原子节点很少时，该方法可以达到最优。在这种方法中优化路径表达式查询的一个中心思想是设法缩小查询范围。使得不需要遍历整个树就可以获得符合条件的查询结果。 2.2路径分解法 这一种方法是目前用的比较多的，它的基本思路是将复杂的查询路径分解成简单路径，简单路径可以是由一个元素、一个谓词条件或一个元素加一个谓词条件，还可以是由两个元素组成的路径。首先计算这些简单路径表达式，再将每个简单路径表达式的计算结果连接起来。其本质确定节点间的结构关系(祖先后代或父子关系)，因此这种操作叫结构连接。像关系数据库中的连接运算一样，结构连接操作的代价非常昂贵，结构连接又是查询处理的核心操作，因此在这种查询处理模式中查询优化的关键开发高效的结构连接算法，同时结构连接的顺序也极大地影响着结构连接运算的性能。 3路径表达查询优化的一般方法 3.1路径表达式的重写优化 路径表达式重写优化的基本思想将复杂的、高代价的查询路径表达式转换为简单的、低代价的等价路径表达式。查询重写技术的一般特征可以概括如下：①重写优化发生在查询解析之后查询计划生成之前；②重写优化是将一个查询转换为一个等价的查询；③要使用启发式方法选择查询转换方法，被选择的查询转换方法能改善大多数查询的执行性能；④查询重写的依据通常是查询本身获得信息、完整性约束或数据模式，而不考虑数据以及数据的存储方式和数据的统计信息。 3.1.1根据结构约束删除冗余 最先研究路径表达式最小化问题是和，文献中只对不包括祖先后代边“//”的简单路径表达式进行最小化，而文献研究了不包含*的路径表达式的最小化问题。其基本思想是将查询中的路径表示为查询模式树，根据给定的结构约束，逐步查询模式树中冗余路径节点或冗余谓词。 文献对包含全部操作符{/,//[],*}的路径表达式的最小化进 行了研究，算法的基本思想是递归地从原模式树中查找最小子模式并连接它们，证明了这是一个NP完全问题，同时，它还指出：在对路径表达式分支个数和形状加以一定限制的情况下。表达式最小化算法的复杂度可以达到多项式级。很显然，在实际查询中用户不可能将查询限制成一种特定形式的路径表达式。 3.1.2删除路径表达式中的固有冗余 文献中提出了两种优化策略：缩短路径策略和补路径策略。缩短路径法是试图用等价相对路径取代绝对路径，缩短路径表达式本身，从而降低查询的代价。这种方法利用元素的唯一访问路径、唯一父元素、关键祖先等几个概念把绝对路径表达式转换为相对路径表达式，这样路径表达式的查询匹配就不再从根元素开始，从而缩短了路径表达式查询时间。如假定某查询的绝对路径表达式EIClE2C2E3…CnEn，如果UAP(E2)=C1E2，则可以用C2E3…CnEn代替EIClE2C2E3…CnEn。这里的关键问题确定唯一访问路径、唯一父元素和关键祖先。 在补路径法中定义了互补路径，相对于某元素的互补路径是等价的，这样就可以用补路径替换原查询。其基本思想是把用户书写的复杂的、代价高的查询路径表达式用一些简单的、查询代价低的互补路径表达式来替代。这种策略的目的是减少连接次数和连接结果集的大小，因此怎样确定查询路径的互补路径并进行代价估算成为其关键问题。 3.1.3删除非冗余的通配符步 当在某条路径中一个元素名未知或无关紧要时通常采用通配符。进行路径匹配时，通配符需要和当前节点的所有子节点(或后代节点)匹配，由此可见，通配符的计算代价相当高。文献中提出消除路径表达式中的非冗余的通配符步，从而降低路径表达式的计算代价。为了消除路径中的通配符步，引入一个layer∞ds重写有通配符的路径表达式查询，在形如child：：*/…/child*/ehild1：的查询中，layer axis可以用来替代所有路径通配步，从而把查询等价地表示为Li::t1。这样一方面缩短了路径表达式，另一方面使得系统仅仅加载与查询相关的XML数据，从而大大的优化了查询。 3.2基于树遍历的路径查询优化 基于树遍历的查询优化要使用路径索引缩小搜索范围，这种优化方法的关键问题是要设计出有效合理的便于维护的路径索引。DataGuides算得上是最早的路径索引，也是路径索引中最有影响力的代表。它采用了一种标签路径合并策略对文档结构进行缩减，DmGuides中的每个节点都有一个目标集。这个目标集记录了通过这个标签路径可访问到的数据节点，这样执行一个路径查询时只需要在Dataguides中查找该路径，获得的目标集即为满足条件的查询结果。当文档的数据结构比较规则时Dataguides能很好地缩减文档的结构，从而极大地改善查询的性能。 文献中提出了一种使用图模式(Graph Schemas)缩小查询范围的方法。这里的图模式也起着DataGuides的作用，但是它采用了合并同类边的策略。图模式中的节点叫状态，每个状态都对应一个状态扩展，集即该状态在文档中所对应的节点集。在此基础上文档提出了两种查询优化策略：剪切查询和使用状态扩展集重写查询。剪切查询是将查询的搜索限制在仅与查询结果有关的子树上，后者则是将原查询改写为在图模式上的查询，两种方法都使用非确定自动机为剪切工具。 不同于以上两种方式，文献提出了一种新的路径查询方法，该方法将XML文档中的文本数据抽取出来单独存储，这样文档树仅由带标签的元素或属性组成，这样的结构被叫做文档的骨架(skeleton)。为了使大的文档的骨架尽可能地放入内存中。这个树骨架进一步通过共享的公共子树被压缩，被压缩的树骨架的每个节点与未压缩树的一组节点相对应，他们之间的对应关系用双向相似关系表示。 3.3基于路径分解的查询优化 结构连接是基于节点在NML文档中的位置表示确定XML节点间的包含关系。给定一个祖先(或父)节点集合A和一个后代(或子)节点集合D，结构连接操作的任务就是要用高效的方法找到所有的节点对(ai,di)，其中ai是di的祖先(或父亲)，ai、di分别是A、D中的元素。A、D可能来自索引扫描也可能是某个计算的中间结果。结构连接运算的代价非常昂贵，因此结构连接算法的好坏直接影响着查询的效率，同时结构连接的顺序也极大地影响着结构连接运算的性能。 3.3.1结构连接算法 目前，已经提出的结构连接算法有两种：排序合并[2，3,7,19]和划分方法。排序合并法的主要特点是：①节点采用区域编码确定节点间的结构关系；②要求输入的数据集有序或在数据集上建立索引；③为了快速定位某类节点，可以利用元素索引、路径索引或值索引。文献中提出了一种多谓词合并连接算法(MP-MGJN)，该算法需要多次扫描数据集；文献中提出的ε－jion、εA－lion和κe-iion算法存在同样的缺点。文献提出了两类算法：树合并(Tree-Merge)算法和堆栈合并(stack-Tree)算法，前者是传统数据库合并连接的推广，后者是一种基于堆栈的结构连接的算法，通过内存中保留一个栈结构来达到对输入数据的一次扫描的目标。文献对Stack-Tree算法做了改进，利用附加的索引跳过不需要参加连接的节点。堆栈合并算法(stack-Tree)既可以应用在XML的关系存储系统中，也可以应用在原生XML系统中。 除了基于区域编码的结构连接算法，文献目中还针对它提出的PBiTree编码提出了基于划分的结构连接算法，其划分策略有两种：水平划分和垂直划分，分别按节点在树中的高度和所在分支对数据集合的划分，这种算法不要求输入的数据有序或建立索引。结构连接算法在一定程度上依赖于节点的编码方法，目前普遍使用的编码方法是区域编码。由于使用区域编码可以快速确定节点间的包含关系，开发高效基于区域编码的结构连接算法仍然是一个值得研究的课题。 3.3.2结构连接的顺序选择 在结构连接中，无论采用什么样的结构连接算法，结构连接的顺序极大地影响着结构连接运算的性能，文献使用简单的代价估算模型提出了5种结构连接的顺序选择算法。其基本思想是使用动态规划算法在整个解空间中搜索代价最小的连接计划，当连接节点过多时解空间会发生组合爆炸，使用动态规划算法进行搜索将会变得非常缓慢。为了加速搜索速度，在动态规划算法中引入了各种不同的启发式规则，这虽然极大地提高了搜索速度却冒着一些可能丢失最优解的风险。结构连接顺序选择的目标是用较小的代价获得最优的连接计划，要实现这个目标还有待于新的结构连接顺序选择算法的提出。 4总结 在众多数据库的应用实例中, 查询操作所占的比重最大, 数据库管理系统中80%的工作是用于数据的查询和检索, 因此数据查询的快慢将直接影响到数据库系统的性能。为了优化数据库系统的性能, 我们通过改进数据库使用的硬件条件、软件环境和规范化设计外, 还应进行数据查询的优化。查询优化在关系数据库中是非常重要的, 优化的目标是避免磁盘I/O瓶颈、减少CPU利用率和减少资源, 能实现快速的数据查询。 1 查询优化 数据库管理系统中的主要操作就是对数据的查询, 为提高数据库的性能, 查询优化必不可少。在实际的应用中, 要尽可能避免排序 (Sort) 、连接 (Join) 和相关子查询操作。笔者认为查询优化要做到以下几点: 1.1 SQL语句优化 (1) 查询时要尽量减少对数据库的访问次数, 不要过多地使用通配符, 如:select * from STUDENT , 要用到几列就选择几列, 如:select sno, sname from STUDENT。 (2) 避免使用不兼容的数据类型, 如:float和int、char和varchar等。数据类型的不兼容可能导致一些语句无法进行优化操作。如:select name from teacher where salary>5 000, 在这里salary是money类型的, 而5 000是一个整数, 在程序编写的过程中就会将money变换为整数, 而不是在运行时才转换。 (3) 尽量避免在WHERE子句中对字段进行函数或表达式操作, 这将导致引擎放弃使用索引而进行全表扫描。 如:SELECT * FROM sc WHERE grade1/2=200 应改为: SELECT * FROM sc WHERE grade=200*2 即:投影操作会导致全表扫描, 它包括数据库函数、计算表达式等, 查询时要尽可能将操作移至等号右边。 (4) 不要有超过5个以上的表连接 (JOIN) 。连接的表越多, 其编译的时间和连接的开销也越大, 性能也越不好控制, 最好是把连接拆开成较小的几个部分逐个顺序执行, 优先执行那些能够大量减少结果的连接。拆分的好处不仅仅是减少SQL Server优化的时间, 更使得SQL语句能够以你可以预测的方式和顺序执行。考虑使用临时表或表变量存放中间结果, 少用子查询。如果一定需要连接很多表才能得到数据, 那么也就意味着数据库在设计时存在很大的缺陷。 (5) 使用视图加速查询。把表的一个子集进行排序并创建视图。它有助于避免多重排序操作, 而且在其他方面还能简化优化器的工作。 1.2 操作符优化 (1) 避免使用!=或<>、IS NULL或IS NOT NULL、IN、NOT IN等这样的操作符, 因为这会使系统无法使用索引而只能直接搜索表中的数据。例如: SELECT sno FROM student WHERE sno!= '2009101%', 优化器将无法通过索引来确定将要命中的行数, 因此需要搜索该表的所有行。NOT IN此操作符是强烈不建议使用的, 因为它不能应用表的索引。推荐方案:用NOT EXISTS 方案代替 。 (2) > 及 < 操作符 (大于或小于操作符) 一般情况下是不用调整的, 因为它有索引就会采用索引查找。但有的情况下可以对它进行优化, 如一个表有200万记录, 一个数值型字段A, 60万记录的A=0, 60万记录的A=1, 79万记录的A=2, 1万记录的A=3。那么执行A>2与A>=3的效果就有很大的区别了, 因为A>2时SQL会先找出为2的记录索引再进行比较, 而A>=3时SQL则直接找到=3的记录索引。 (3) LIKE操作符可以应用通配符查询, 里面的通配符组合可以实现几乎是任意的查询。但是如果用得不好, 则会产生性能上的问题, 如LIKE ‘%3600%’ 这种查询不会引用索引, 而LIKE ‘a3600%’则会引用范围索引。 1.3 使用存储过程 存储过程是一个可重用的代码模块, 可以高效率地完成指定的操作。存储过程允许用户进行模块化程序设计, 大大提高了程序的设计效率, 存储过程创建后, 可以在程序中任意调用, 减少了重新编译的时间。同时, 存储过程也减少了客户端和服务器的繁复交互。如果程序发布后需要做某些改变, 则可以直接修改存储过程而不用修改程序, 从而提高效率。 2 索引优化 对于查询的优化, 数据库管理系统通常采用索引技术来加快对表中数据的检索。索引允许数据库应用程序迅速找到表中的数据, 而不必扫描整个数据库。索引是一种表或视图关联的物理结构, 可以用来加快从表或视图中检索数据行的速度。通过创建索引可以保证每一行数据的唯一性, 可以大大加快数据的检索速度, 也可以加快表和表之间的连接。在使用order by和group by子句进行数据查询时, 可以减少查询中的分组和排序时间, 且可以在查询的过程中使用优化隐藏器, 提高系统的性能。 2.1 索引的分类 聚集索引:将表中的记录在物理数据页中的位置按索引字段值重新排序, 再将重排后的结果写回到磁盘上。每个表只能有一个聚集索引 。 非聚集索引:与表中数据行的实际存储结构无关, 不会改变数据表中记录的实际存储顺序, 每个表可以有多个非聚集索引 。 唯一索引:要求创建索引的关键字段值在表中不能有重复值 。 复合索引:对表创建的索引是基于多个字段对表中的记录排序的。复合索引中字段的顺序是非常重要的, 越是唯一的字段越是要靠前。 2.2 创建索引的原则 (1) 在经常用来检索的列上创建索引 (如经常在where子句中出现的列) 。 (2) 在表的主键、外键上创建索引。 (3) 在经常用于表间连接的字段上建立索引。 (4) 一般而言, 如下情况的列不考虑在其上创建索引:①在查询中几乎不涉及的列;②很少有唯一值的列 (即包含太多重复值得列, 如性别字段) ;③数据类型为text、ntext或image的列。 (5) 只有较少行数的表没有必要创建索引。 (6) 当写的性能比查询更重要时, 应少建或不建索引。 2.3 索引优化 (1) 聚集索引和非聚集索引的使用情况。 我们可以通过聚集索引和非聚集索引的定义来理解表1内容。比如您的某个学生表有一个学号列, 恰好您把聚合索引建立在该列, 这时您查询学号为200901001-200901100间的全部数据时, 这个速度将会是很快的, 因为您的这本字典正文是按学号进行排序的, 聚类索引只需要找到要检索的所有数据中的开头和结尾数据即可, 而不像非聚集索引, 必须先到目录中查询每一项数据对应的页码, 然后再根据页码查到具体内容。 (2) 使用短索引。 对串列进行索引, 如果可能则应该指定一个前缀长度。例如, 如果有一个CHAR (255) 的 列, 若在前15 个或25 个字符内, 多数值是惟一的, 那么就不要对整个列进行索引。短索引不仅可以提高查询速度, 而且可以节省磁盘空间并减少I/O操作。 2.4 索引管理 索引创建后, 由于数据的增加、删除、更新等操作使得索引页出现碎块。为了提高性能, 必须对索引进行维护, 这些维护包括查看碎块信息、维护统计信息、分析索引性能及删除重建索引等。 (1) 查看索引统计信息。 索引统计信息是查询优化器用来分析和评估查询, 并确定最优查询计划的基础数据。索引统计信息的作用颇为关键, 随着列中数据的更改, 索引和列的统计信息会自动更新保持一致, 如果统计信息停用, 可能导致查询优化器参考错误的统计信息, 从而使用错误的执行计划, 所以我们要随时掌握统计信息的动态。比如, 在一个包含1 000行数据的表上创建索引, 索引列中包含的数据都是唯一值, 查询优化器把该索引列视为搜集查询数据的最好方法。如果更新活动频繁发生, 使得索引列中的数据有很多重复值, 则该列对于查询不再是理想的候选列。 (2) 查看索引碎片信息。 在数据使用了一段时间后, 必然会产生碎片, 产生碎片后, 使用索引的效率就会降低, 进而导致查询的效率降低。为了应对索引碎片, 一般比较好的办法就是重新建立或重新整理碎片来组织索引, 重新填满数据块.并除去数据碎片。如果碎片很小, 则不需要重新生成或重新组织碎片, 如果碎片小于30%, 则可以选择重新组织索引, 如果碎片大于30%, 则可以重新生成索引。 (3) 维护索引统计信息。 统计信息是存储在SQL中的列数据样本, 这些数据一般用于索引列, 但是还可以为非索引列创建统计, 查询的优化依赖于这些统计信息的分布准确度, 查询优化器使用这些数据样本来决定使用表扫描或使用索引。使用UPDATE STATISTICS语句维护索引统计信息, 重新更新了索引的统计信息, 这样有利于系统准确地选择索引。 3结语 在数据库应用开发过程中, 要使性能缓慢的数据库系统运行得更快、更高效, 不但需要整体分析数据库系统, 找出系统的性能瓶颈, 更需要优化数据库系统发出的SQL语句, 一旦找出关键的SQL语句便加以优化。本文只是针对数据库中SQL查询的优化进行了分析, 并提出了一些建议, 以解决数据库系统的性能问题。 参考文献 [1]闪四清.SQL SERVER2005数据库应用[M].北京:清华大学出版社, 2009. [2]许平格.数据库管理系统中查询优化的设计和实现[D].杭州:浙江大学, 2005. [3]萨师宣, 王珊.数据库系统概论[M].北京:高等教育出版社, 2002. [4]王嘉佳, 马江涛, 许伟.数据库基础教程[M].北京:清华大学出版社, 2009. 【数据库查询优化】推荐阅读： Web数据库查询09-03 数据库的高级查询操作08-17 分布数据查询07-03 串口数据发布与查询09-08 数据库操作优化09-13 数据库性能的优化05-29 数据优化处理08-13 网络优化数据挖掘05-30 Excel数据优化教案07-09 从维护到优化：充分利用你的客户数据06-26数据库的查询优化方法分析 篇4
1.13 数据库查询语言 篇5
数据库查询优化 篇6
浅谈数据库查询优化技术 篇7
数据库查询优化技术的研究 篇8
分布式数据库查询优化方法 篇9
并行数据库系统的查询优化研究 篇10
XML路径表达式的查询优化技术 篇11
数据库查询优化 篇12