查询优化（通用11篇）
查询优化 篇1
1 引言
在IT技术高速发展, 互联网已渗透至千家万户的今天, 数据库技术始终居于中心地位。任何一个投入运行的信息系统中, 都会有一个数据库管理系统作为支撑。在所有数据库管理系统中, SQL Server则由于出自Microsoft公司, 与Windows操作系统的紧密集成, 以及方便易用的图形界面, 而处于极其重要的位置。SQL Server是一个数据库管理系统, 它采用了单进程、多线索技术, 支持存储过程, 采用基于成本的优化技术, 在核心层实现数据完整性约束, 并具有很强的安全保密性。它的工作主要是负责高速计算, 数据管理, 安全性及事务管理。
优化对于改善SQL Server性能至关重要, 可以通过降低网络流量、减少磁盘I/O和降低CPU时间, 最大化所有用户的处理吞吐量, 以提供每个查询可以接受的响应时间。在SQL Server性能的优化中, 数据查询的优化是一个重要的优化方法。本文在分析传统数据库管理系统查询优化技术的基础上, 提出了通过面向对象的方法来实现SQL Server的查询优化。
2 数据库的查询优化技术概述
对于每一个查询, Microsoft SQL Server数据库内核用优化器优化向SQL提交的数据操作。这个优化过程首先进行查询分析, 判断每一个子句能否被优化。对不能优化的子句采用全表扫描, 可优化的子句, 则由优化器执行索引选择。索引选择确定可用的索引, 并估算每个子句的开销。下面简单叙述一下SQL Server的查询优化技术:
2.1 自动查询优化技术
SQL Server的自动查询优化技术是通过基于开销的查询优化器来实现的。当提交一条SQL语句时, 该语句只是指出想要从数据库中得到什么结果, 而不是怎样得到结果。SQLServer使用基于开销的优化器, 以CPU使用, 磁盘I/O作为度量方式, 优化器为每个可能的执行规划赋予一个开销值, 然后优化器选择一个开销值最小的执行规划。查询优化所做的工作很复杂, 要找出最优执行规划, 优化器要考虑数以千计的因素。除了检查统计数据来决定以合适的方式使用索引外, 优化器还必须考虑访问表的顺序、所采用的连接算法、合适的排序算法, 以及许多其他细节方面的问题。当提交给查询处理器时, 只要比较两个输入来产生一个输出时, 就会用到连接操作。连接操作可以在表与表之间, 索引和表间, 以及索引和索引之间使用。SQL Server查询处理器会使用三种类型的连接策略:嵌套循环连接、合并连接和哈希连接。优化器必须考虑每个算法以决定对于给定情况的最合适算法。
2.2 索引技术
索引是一个单独的、物理的数据库结构, 它是某个表中一列或若干列值的集合和相应的指向表中物理标识这些值的数据页的逻辑指针清单表的存储由两部分组成一部分用来存放数据页面, 另一部分存放索引页面。通常索引页面相对于数据页面来说小得多。数据检索花费的大部分开销是磁盘读写, 没有索引就需要从磁盘上读表的每一个数据页, 如果有索引, 则只需查找索引页面就可以了。所以建立合理的索引, 就能加速数据的检索过程。
SQL Server采用B-树结构的索引, 根据索引的顺序与数据表的物理顺序是否相同可以分为:聚簇索引 (clustered index) 和非聚簇索引 (nonclustered index) 。
一般来说建立索引应注意以下几点:
(1) 主键时常作为where子句的条件, 应在表的主键列上建立簇索引, 尤其当经常用它作为连接的时候;
(2) 有大量重复值且经常有范围查询和排序、分组发生的列, 或者非常频繁地被访问的列, 可考虑建立簇索引;
(3) 经常同时存取多列, 且每列都含有重复值可考虑建立复合索引来覆盖一个或一组查询, 并把查询引用最频繁的列作为前导列, 如果可能尽量使关键查询形成覆盖查询;
(4) 如果知道索引键的所有值都是唯一的, 那么确保把索引定义成唯一索引;
(5) 在一个经常做插入操作的表上建索引时, 使用fillfactor (填充因子) 来减少页分裂, 同时提高并发度, 降低死锁的发生。如果在只读表上建索引, 则可以把fillfactor设为100;
(6) 在选择索引键时, 设法选择那些采用小数据类型的列作为键以使每个索引页能够容纳尽可能多的索引键和指针, 通过这种方式, 可使一个查询必须遍历的索引页面降到最小。此外, 尽可能地使用整数为键值, 因为它能够提供比任何数据类型都快的访问速度。
2.3 存储过程的使用
随着Client/Server的应用程序的广泛使用, 如何充分利用网络资源、减少网络流量是提高应用查询性能的一个重要因素, 而存储过程的使用则是减少网络流量, 加快执行速度的必要环节。
存储过程是SQL Server服务器上一组预先定义并编译好的Transact-SQL语句, 它可以接受参数、返回状态值和参数值, 并且还可以嵌套调用。当一个存储过程被第一次运行时, SQL Server将该存储过程放入内存并完全编译 (不必进行词法分析与规范化, 因为在存储过程被创建时, 这些工作就已经完成了) , 在该存储过程被再次调用时 (无论是由同一用户还是不同用户调用) , 可以被马上处理, 而没有任何额外开销。另外, 存储过程是一种模式化的程序设计, 在Client/Server的应用程序中, 使用存储过程可以方便地进行程序设计, 减少程序员的工作量。
3 使用面向对象的方法实现SQL Server的查询优化
面向对象方法 (Object-Oriented Method) 是一种把面向对象的思想应用于软件开发过程中, 指导开发活动的系统方法, 简称OO (Object-Oriented) 方法, 是建立在“对象”概念基础上的方法学。对象是由数据和容许的操作组成的封装体, 与客观实体有直接对应关系, 一个对象类定义了具有相似性质的一组对象。而每继承性是对具有层次关系的类的属性和操作进行共享的一种方式。所谓面向对象就是基于对象概念, 以对象为中心, 以类和继承为构造机制, 来认识、理解、刻画客观世界和设计、构建相应的软件系统。
而如何将面向对象的方法运用到SQL Server的查询中去, 首先我们需要对SQL语句进行分析, 用类来归纳和构建SQL语句。
3.1 SELECT语句的语法结构分析
整个SELECT语句可以表示成为7个类。
(1) 表达式类 (expression) 。
(2) 字段类 (field) 。
(3) 数据类 (data) 。
(4) 数据表类 (table) 。
(5) 数据类型类 (type) 。
(6) SQL关键字类 (SQLKEY) 。
(7) 运算符类 (operator) 。
3.2 SQL SERVER查询语句的面向对象模型
图1是使用以上7个类的面向对象模型。
从模型可以看出, 本文构建的SQL语句面向对象的模型用户可以方便直观的创建、删除、合并、拆分各种类型的表达式, 无需记忆程序内部处理字段、函数等SQL语法的具体形式。达到了提高SQL SERVER中查询语句的运行效率目的提高了的性能
4 结语
随着Internet的日益普及, 基于SQL Server的应用程序, 其应用范围也越来越广。而数据库系统查询是数据库系统设计和实现中的一个重要步骤, 也是基于SQL Server应用程序设计时的一个重要问题。本文在分析了传统SQL Server查询优化的基础上, 提出了通过面向对象方法构建对象类来解析SQL查询语句, 使得用户能够用户可以方便直观的创建SQL Server中的查询语句, 而不用去关心内部的细节问题使得整个数据查询可以高效透明的进行.
参考文献
[1]龙守谌, 叶乃文, 邝劲筠.Microsoft SQL Server 6.5培训教程[M].北京:人民邮电出版社, 1998.
[2]车争, 夏巨谌, 胡国安, 张宜生.基于SQL Server的数据库与应用程序的优化[J].计算机辅助工程, NO.4 Dec, 2002.
[3]胡江奕, 任宏萍, 毛法尧.基于SQL Server的应用程序的优化[J].计算机工程与应用, 1998, (10) .
[4]骆翔宇, 成良玉.用面向对象方法设计并实现数据库的动态查询[J].计算机工程与应用, 2003, (15) .
查询优化 篇2
这一部分讲述了索引是什么以及索引是怎么样提高查询性能的。它还讨论了在某些环境中索引可能降低性能，并为你明智地选择数据表的索引提供了一些指导方针。在下一部分中我们将讨论MySQL查询优化器，它试图找到执行查询的效率最高的方法。了解一些优化器的知识，作为对如何建立索引的补充，对我们是有好处的，因为这样你才能更好地利用自己所建立的索引。某些编写查询的方法实际上让索引不起作用，在一般情况下你应该避免这种情形的发生。
索引的优点
让我们开始了解索引是如何工作的，首先有一个不带索引的数据表。不带索引的表仅仅是一个无序的数据行集合。例如，图1显示的ad表就是不带索引的表，因此如果需要查找某个特定的公司，就必须检查表中的每个数据行看它是否与目标值相匹配。这会导致一次完全的数据表扫描，这个过程会很慢，如果这个表很大，但是只包含少量的符合条件的记录，那么效率会非常低。
图1：无索引的ad表
图2是同样的一张数据表，但是增加了对ad表的company_num数据列的索引。这个索引包含了ad表中的每个数据行的条目，但是索引的条目是按照company_num值排序的。现在，我们不是逐行查看以搜寻匹配的数据项，而是使用索引。假设我们查找公司13的所有数据行。我们开始扫描索引并找到了该公司的三个值。接着我们碰到了公司14的索引值，它比我们正在搜寻的值大。索引值是排过序的，因此当我们读取了包含14的索引记录的时候，我们就知道再也不会有更多的匹配记录，可以结束查询操作了。因此使用索引获得的功效是：我们找到了匹配的数据行在哪儿终止，并能够忽略其它的数据行。另一个功效来自使用定位算法查找第一条匹配的条目，而不需要从索引头开始执行线性扫描（例如，二分搜索就比线性扫描要快一些）。通过使用这种方法，我们可以快速地定位第一个匹配的值，节省了大量的搜索时间。数据库使用了多种技术来快速地定位索引值，但是在本文中我们不关心这些技术。重点是它们能够实现，并且索引是个好东西。
图2：索引后的ad表
你可能要问，我们为什么不对数据行进行排序从而省掉索引？这样不是也能实现同样的搜索速度的改善吗？是的，如果表只有一个索引，这样做也可能达到相同的效果。但是你可能添加第二个索引，那么就无法一次使用两种不同方法对数据行进行排序了（例如，你可能希望在顾客名称上建立一个索引，在顾客ID号或电话号码上建立另外一个索引）。把与数据行相分离的条目作为索引解决了这个问题，允许我们创建多个索引。此外，索引中的行一般也比数据行短一些。当你插入或删除新的值的时候，移动较短的索引值比移动较长数据行的排序次序更加容易。
不同的MySQL存储引擎的索引实现的具体细节信息是不同的。例如，对于MyISAM数据表，该表的数据行保存在一个数据文件中，索引值保存在索引文件中。一个数据表上可能有多个索引，但是它们都被存储在同一个索引文件中。索引文件中的每个索引都包含一个排序的键记录（它用于快速地访问数据文件）数组。
与此形成对照的是，BDB和InnoDB存储引擎没有使用这种方法来分离数据行和索引值，尽管它们也把索引作为排序后的值集合进行操作。在默认情况下，BDB引擎使用单个文件存储数据和索引值。InnoDB使用单个数据表空间（tablespace），在表空间中管理所有InnoDB表的数据和索引存储。我们可以把InnoDB配置为每个表都在自己的表空间中创建，但是即使是这样，数据表的数据和索引也存储在同一个表空间文件中。
前面的讨论描述了单个表查询环境下的索引的优点，在这种情况下，通过减少对整个表的扫描，使用索引明显地提高了搜索的速度。当你运行涉及多表联结（jion）查询的时候，索引的价值就更高了。在单表查询中，你需要在每个数据列上检查的值的数量是表中数据行的数量。在多表查询中，这个数量可能大幅度上升，因为这个数量是这些表中数据行的数量所产生的。
假设你拥有三个未索引的表t1、t2和t3，每个表都分别包含数据列i1、i2和i3，并且每个表都包含了1000条数据行，其序号从1到1000。查找某些值匹配的数据行组合的查询可能如下所示：
SELECT t1.i1, t2.i2, t3.i3
FROM t1, t2, t3
WHERE t1.i1 = t2.i2 AND t2.i1 = t3.i3;
这个查询的结果应该是1000行，每个数据行包含三个相等的值。如果在没有索引的情况下处理这个查询，那么如果我们不对这些表进行全部地扫描，我们是没有办法知道哪些数据行含有哪些值的。因此你必须尝试所有的组合来查找符合WHERE条件的记录。可能的组合的数量是1000 x 1000 x 1000（10亿！），它是匹配记录的数量的一百万倍。这就浪费了大量的工作。这个例子显示，如果没有使用索引，随着表的记录不断增长，处理这些表的联结所花费的时间增长得更快，导致性能很差。我们可以通过索引这些数据表来显著地提高速度，因为索引让查询采用如下所示的方式来处理：
1．选择表t1中的第一行并查看该数据行的值。
2．使用表t2上的索引，直接定位到与t1的值匹配的数据行。类似地，使用表t3上的索引，直接定位到与表t2的值匹配的数据行。
3．处理表t1的下一行并重复前面的过程。执行这样的操作直到t1中的所有数据行都被检查过。
在这种情况下，我们仍然对表t1执行了完整的扫描，但是我们可以在t2和t3上执行索引查找，从这些表中直接地获取数据行。理论上采用这种方式运行上面的查询会快一百万倍。当然这个例子是为了得出结论来人为建立的。然而，它解决的问题却是现实的，给没有索引的表添加索引通常会获得惊人的性能提高。
MySQL有几种使用索引的方式：
· 如上所述，索引被用于提高WHERE条件的数据行匹配或者执行联结操作时匹配其它表的数据行的搜索速度。
· 对于使用了MIN()或MAX()函数的查询，索引数据列中最小或最大值可以很快地找到，不用检查每个数据行。
· MySQL利用索引来快速地执行ORDER BY和GROUP BY语句的排序和分组操作。
· 有时候MySQL会利用索引来读取查询得到的所有信息。假设你选择了MyISAM表中的被索引的数值列，那么就不需要从该数据表中选择其它的数据列。在这种情况下，MySQL从索引文件中读取索引值，它所得到的值与读取数据文件得到的值是相同的。没有必要两次读取相同的值，因此没有必要考虑数据文件。
索引的代价
一般来说，如果MySQL能够找到方法，利用索引来更快地处理查询，它就会这样做。这意味着，对于大多数情况，如果你没有对表进行索引，就会使性能受到损害。这就是我所描绘的索引优点的美景。但是它有缺点吗？有的，它在时间和空间上都有开销。在实践中，索引的优点的价值一般会超过这些缺点，但是你也应该知道到底有一些什么缺点。
首先，索引加快了检索的速度，但是减慢了插入和删除的速度，同时还减慢了更新被索引的数据列中的值的速度。也就是说，索引减慢了大多数涉及写操作的速度。发生这种现象的原因在于写入一条记录的时候不但需要写入数据行，还需要改变所有的索引。数据表带有的索引越多，需要做出的修改就越多，平均性能的降低程度也就越大。在本文的“高效率载入数据”部分中，我们将更细致地了解这些现象并找出处理方法。
其次，索引会花费磁盘空间，多个索引相应地花费更多的磁盘空间。这可能导致更快地到达数据表的大小限制：
· 对于MyISAM表，频繁地索引可能引起索引文件比数据文件更快地达到最大限制。
· 对于BDB表，它把数据和索引值一起存储在同一个文件中，添加索引引起这种表更快地达到最大文件限制。
在InnoDB的共享表空间中分配的所有表都竞争使用相同的公共空间池，因此添加索引会更快地耗尽表空间中的存储。但是，与MyISAM和BDB表使用的文件不同，InnoDB共享表空间并不受操作系统的文件大小限制，因为我们可以把它配置成使用多个文件。只要有额外的磁盘空间，你就可以通过添加新组件来扩展表空间。
使用单独表空间的InnoDB表与BDB表受到的约束是一样的，因为它的数据和索引值都存储在单个文件中，
这些要素的实际含义是：如果你不需要使用特殊的索引帮助查询执行得更快，就不要建立索引。
选择索引
假设你已经知道了建立索引的语法，但是语法不会告诉你数据表应该如何索引。这要求我们考虑数据表的使用方式。这一部分指导你如何识别出用于索引的备选数据列，以及如何最好地建立索引：
用于搜索、排序和分组的索引数据列并不仅仅是用于输出显示的。换句话说，用于索引的最好的备选数据列是那些出现在WHERE子句、join子句、ORDER BY或GROUP BY子句中的列。仅仅出现在SELECT关键字后面的输出数据列列表中的数据列不是很好的备选列：
SELECT
col_a <- 不是备选列
FROM
tbl1 LEFT JOIN tbl2
ON tbl1.col_b = tbl2.col_c <- 备选列
WHERE
col_d = expr; <- 备选列
当然，显示的数据列与WHERE子句中使用的数据列也可能相同。我们的观点是输出列表中的数据列本质上不是用于索引的很好的备选列。
Join子句或WHERE子句中类似col1 = col2形式的表达式中的数据列都是特别好的索引备选列。前面显示的查询中的col_b和col_c就是这样的例子。如果MySQL能够利用联结列来优化查询，它一定会通过减少整表扫描来大幅度减少潜在的表－行组合。
考虑数据列的基数（cardinality）。基数是数据列所包含的不同值的数量。例如，某个数据列包含值1、3、7、4、7、3，那么它的基数就是4。索引的基数相对于数据表行数较高（也就是说，列中包含很多不同的值，重复的值很少）的时候，它的工作效果最好。如果某数据列含有很多不同的年龄，索引会很快地分辨数据行。如果某个数据列用于记录性别（只有“M”和“F”两种值），那么索引的用处就不大。如果值出现的几率几乎相等，那么无论搜索哪个值都可能得到一半的数据行。在这些情况下，最好根本不要使用索引，因为查询优化器发现某个值出现在表的数据行中的百分比很高的时候，它一般会忽略索引，进行全表扫描。惯用的百分比界线是“30%”。现在查询优化器更加复杂，把其它一些因素也考虑进去了，因此这个百分比并不是MySQL决定选择使用扫描还是索引的唯一因素。
索引较短的值。尽可能地使用较小的数据类型。例如，如果MEDIUMINT足够保存你需要存储的值，就不要使用BIGINT数据列。如果你的值不会长于25个字符，就不要使用CHAR(100)。较小的值通过几个方面改善了索引的处理速度：
· 较短的值可以更快地进行比较，因此索引的查找速度更快了。
· 较小的值导致较小的索引，需要更少的磁盘I/O。
· 使用较短的键值的时候，键缓存中的索引块（block）可以保存更多的键值。MySQL可以在内存中一次保持更多的键，在不需要从磁盘读取额外的索引块的情况下，提高键值定位的可能性。
对于InnoDB和BDB等使用聚簇索引（clustered index）的存储引擎来说，保持主键（primary key）短小的优势更突出。聚簇索引中数据行和主键值存储在一起（聚簇在一起）。其它的索引都是次级索引；它们存储主键值和次级索引值。次级索引屈从主键值，它们被用于定位数据行。这暗示主键值都被复制到每个次级索引中，因此如果主键值很长，每个次级索引就需要更多的额外空间。
索引字符串值的前缀（prefixe）。如果你需要索引一个字符串数据列，那么最好在任何适当的情况下都应该指定前缀长度。例如，如果有CHAR(200)数据列，如果前面10个或20个字符都不同，就不要索引整个数据列。索引前面10个或20个字符会节省大量的空间，并且可能使你的查询速度更快。通过索引较短的值，你可以获得那些与比较速度和磁盘I/O节省相关的好处。当然你也需要利用常识。仅仅索引某个数据列的第一个字符串可能用处不大，因为如果这样操作，那么在索引中不会有太多的唯一值。
你可以索引CHAR、VARCHAR、BINARY、VARBINARY、BLOB和TEXT数据列的前缀。
使用最左（leftmost）前缀。建立多列复合索引的时候，你实际上建立了MySQL可以使用的多个索引。复合索引可以作为多个索引使用，因为索引中最左边的列集合都可以用于匹配数据行。这种列集合被称为“最左前缀”（它与索引某个列的前缀不同，那种索引把某个列的前面几个字符作为索引值）。
假设你在表的state、city和zip数据列上建立了复合索引。索引中的数据行按照state/city/zip次序排列，因此它们也会自动地按照state/city和state次序排列。这意味着，即使你在查询中只指定了state值，或者指定state和city值，MySQL也可以使用这个索引。因此，这个索引可以被用于搜索如下所示的数据列组合：
state, city, zip
state, city
state
MySQL不能利用这个索引来搜索没有包含在最左前缀的内容。例如，如果你按照city或zip来搜索，就不会使用到这个索引。如果你搜索给定的state和具体的ZIP代码（索引的1和3列），该索引也是不能用于这种组合值的，尽管MySQL可以利用索引来查找匹配的state从而缩小搜索的范围。
不要过多地索引。不要认为“索引越多，性能越高”，不要对每个数据列都进行索引。我们在前面提到过，每个额外的索引都会花费更多的磁盘空间，并降低写操作的性能。当你修改表的内容的时候，索引就必须被更新，甚至可能重新整理。如果你的索引很少使用或永不使用，你就没有必要减小表的修改操作的速度。此外，为检索操作生成执行计划的时候，MySQL会考虑索引。建立额外的索引会给查询优化器增加更多的工作量。如果索引太多，有可能（未必）出现MySQL选择最优索引失败的情况。维护自己必须的索引可以帮助查询优化器来避免这类错误。
如果你考虑给已经索引过的表添加索引，那么就要考虑你将增加的索引是否是已有的多列索引的最左前缀。如果是这样的，不用增加索引，因为已经有了（例如，如果你在state、city和zip上建立了索引，那么没有必要再增加state的索引）。
让索引类型与你所执行的比较的类型相匹配。在你建立索引的时候，大多数存储引擎会选择它们将使用的索引实现。例如，InnoDB通常使用B树索引。MySQL也使用B树索引，它只在三维数据类型上使用R树索引。但是，MEMORY存储引擎支持散列索引和B树索引，并允许你选择使用哪种索引。为了选择索引类型，需要考虑在索引数据列上将执行的比较操作类型：
· 对于散列（hash）索引，会在每个数据列值上应用散列函数。生成的结果散列值存储在索引中，并用于执行查询。散列函数实现的算法类似于为不同的输入值生成不同的散列值。使用散列值的好处是散列值比原始值的比较效率更高。散列索引用于执行=或<=>操作等精确匹配的时候速度非常快。但是对于查询一个值的范围效果就非常差了：
id < 30
weight BETWEEN 100 AND 150
· B树索引可以用于高效率地执行精确的或者基于范围（使用操作<、<=、=、>=、>、、!=和BETWEEN）的比较。B树索引也可以用于LIKE模式匹配，前提是该模式以文字串而不是通配符开头。
如果你使用的MEMORY数据表只进行精确值查询，散列索引是很好的选择。这是MEMORY表使用的默认的索引类型，因此你不需要特意指定。如果你希望在MEMORY表上执行基于范围的比较，应该使用B树索引。为了指定这种索引类型，需要给索引定义添加USING BTREE。例如：
CREATE TABLE lookup
(
id INT NOT NULL,
name CHAR(20),
PRIMARY KEY USING BTREE (id)
) ENGINE = MEMORY;
如果你希望执行的语句的类型允许，单个MEMORY表可以同时拥有散列索引和B树索引，即使在同一个数据列上。
有些类型的比较不能使用索引。如果你只是通过把值传递到函数（例如STRCMP()）中来执行比较操作，那么对它进行索引就没有价值。服务器必须计算出每个数据行的函数值，它会排除数据列上索引的使用。
优化贿档查询的四个补丁 篇3
《查询工作规定》的亮点之一就是规定了行贿犯罪档案的“退出”机制。《查询工作规定》第二十三条规定，行贿犯罪信息的查询期限为十年，逾期后，行贿犯罪信息便不向社会提供查询，即行贿犯罪信息只有十年的在档期限，超过十年则自动退档。而在实际操作中，这种“一刀切”的规定有一定的不合理之处。
首先，行贿犯罪的情节有轻有重，数额有大有小，对于一些犯罪情节严重、数额巨大的责任主体，十年的犯罪信息在档期可以使其改过自新、重新做人。而对那些犯罪情节较轻、数额不大的责任主体而言，十年犯罪信息在档期则显得过长。因此，有必要将行贿犯罪记录在档期参照刑法关于追诉时效的规定，划分两到三个不同的档次。
其次，对于成立时间尚不足十年的单位而言，将查询期限设定为十年并不合适。一是作为具有法律效力的正式告知函，将一个公司成立之前的时间作为查询范围显得不够严肃；二是可能会产生错误的查询结果。我国《企业名称登记管理实施办法》规定，企业变更名称满一年，原名称注销登记。另外，被吊销营业执照满三年的企业名称，可以再次使用该名称注册成立公司。如果某企业恰好使用了该类企业名称，而该名称的原企业又有行贿犯罪记录且不满十年的，那么行贿犯罪记录就可能出现在新企业的行贿犯罪档案查询结果里。当然，出现这种结果后还可以再通过其他信息进行甄别。但是，针对成立时间不足十年的企业，若将查询起始时间设定为成立之日，则可以同时避免上述两个弊端。
取消查询受理地限制
《查询工作规定》第十三条规定：“公司、企业对本公司、企业进行行贿犯罪档案查询的，由公司、企业住所地或者业务发生地人民检察院受理。个人进行行贿犯罪档案查询的，由个人住所地人民检察院受理。”这是对查询受理地首次作出规定，这一规定可能会给一部分申请人带来不便。在正常情况下，大多数申请人在住所地或业务发生地的检察机关进行申请查询。但有时，申请人在住所地或业务发生地以外的检察机关申请更方便。既然行贿犯罪档案查询系统已经实行全国联网，那么无论在何地申请查询，查询结果都是一样的，应当本着方便申请人的原则，取消对查询受理地的限制，允许申请人在全国范围内任一检察机关申请查询。同时规定，对于手续齐全、符合查询条件的，检察机关应当受理。
完善告知函内容
根据《查询工作规定》第二十二条，查询结果告知的内容包括：“是否有行贿犯罪记录；对于有行贿犯罪记录的，应当列明犯罪及判决相关情况；还可附加告知有关整改和预防的信息及其他相关内容。”在实际查询操作中，查询告知函是系统自动生成的固定格式，对于有行贿犯罪记录的，犯罪及判决相关情况会自动生成在告知函中，不会出现问题。但“有关整改和预防的信息”和“其他相关内容”如何添加到告知函中，新规定并未作出进一步解释。
另外，《查询工作规定》第二十一条规定了告知函的有效期，即自出具之日起两个月内有效。这一内容应当作为备注内容自动生成到告知函中。因为有的申请人在出具告知函以后，可能有新的行賄犯罪记录出现，规定告知函有效期的根本目的是防止其长期使用同一告知函规避制裁。因此，告知函的有效期必须让接收方（即要求申请人出具告知函的一方，通常为项目招标方、人员招录方等）知晓，而将有效期备注到告知函中无疑是恰当的方式。
统一列明相关犯罪记录
在对企业的贿档查询操作中，查询结果会出现与该企业相关的某个个人的行贿犯罪记录，但申请人并没有申请对该人进行查询。经查看档案详细记录，发现其中有的个人犯罪行为是为了企业利益实施的，如某建设公司经营管理处主任吴某，在某县人民医院急救病房综合楼相关工程招标时，向该县副县长、县人民医院急救病房综合楼工程指挥长颜某行贿3万元，事后吴某所在公司顺利中标。而有的个人犯罪行为根据档案系统所载内容不能判断是否与企业有关。如某公司销售员高某，在个人代理销售该公司产品时，为了提高销售量，多次送给其客户公司经理于某好处费共计42万元。再如某工程公司经理韦某，为感谢张某利用职务便利在其承接工程项目投标过程中给予的帮助，先后多次给予张某好处费共计81万余元。对于该类个人犯罪记录，在现行查询系统中，允许操作人员对行贿犯罪记录是否出现在告知函里进行选择。而这种可选择的操作模式必然会导致对于同一犯罪记录不同操作人员由于对案情的认识不同而出现不同的操作结果：有的将行贿犯罪记录如实列明于告知函，而有的则可能将犯罪记录勾销。而新规定对此并没有提出相应的细则与办法。
更为严重的是，这种可选择的操作模式还可能会使个别检察机关或操作人员与有行贿犯罪记录的申请人私下达成交易，使行贿犯罪档案查询制度成为个别人谋取私利的工具，引发检察机关内部腐败。从长远来看，这将导致行贿犯罪档案查询制度遏制贿赂犯罪、促进诚信建设的价值和功能大大削减，使这一制度名存实亡。因此，应当对现行查询操作系统进行完善，取消可选择操作模式，使行贿犯罪档案查询成为不可选择的机械式操作，这样才能保证对同一申请人在全国各地查询结果的统一性与唯一性，并体现告知函的严肃性。
行贿犯罪档案查询制度是遏制职务犯罪与腐败滋生的有效手段。虽然贿档查询工作在有些方面还有待研究与改善，但其必然会经历一个不断发展完善的过程。在新形势下，日趋完善的行贿犯罪档案查询制度必将对防控职务犯罪和商业贿赂起到警示和威慑作用，并以此促进市场经济秩序的规范和社会诚信体系的建设。
SQL查询语句优化研究 篇4
关键词：SQL,优化策略,数据库性能,谓词
0 引言
查询是数据库中最基本、最常用、最复杂的操作。在数据库的管理信息系统中,查询操作是所有数据库操作中所占据比重最大的操作。当数据库系统积累到一定程度,若查询时采用单条顺序扫描,那么扫描一遍所有的记录可能就得花上几十分钟,甚至几小时,这样的系统就失去了现实的使用价值。采取什么样的查询策略,使查询时间降为几分钟或者几秒钟,就是这里需要研究的查询优化问题。
1 优化原理[1]
查询优化力图找出给定表达式等价,但执行效率更高的一个表达式,一个查询往往会有许多实现方法,关键是如何找出一个与之等价的且操作时间又少的表达式,查询优化关注的问题是怎样省时、省空间以及效率高。优化的核心问题是尽可能减少查询中各表的参与加工的数据量,从而达到优化时间和空间的目的。
2 SQL优化的方法
2.1 模糊匹配的避免
LIKE关键字支持通配符匹配,技术上称为正则表达式。但这种匹配特别耗费时间,尽量避免使用模糊匹配。例:
即使在rx score字段上建立了索引,在这种情况下也还是采用顺序扫描的方式。
可改写为:
这样,在执行查询时就会利用索引来查询,显然会大大提高速度。
2.2 逻辑表达式的等价变换
由于执行引擎对各种谓词的处理方法不同,因此把逻辑表达式重写成等价的且效率较高的表达式是提高查询效率的有效方法,同时也是切实可行的[2]。通过查阅大量的文献资料以及大量的实验,分析了RDBMS执行引擎对各种谓词执行效率的不同,总结出以下几种逻辑表达式转换规则:
2.2.1 将多个OR连接的表达式转化为ANY表达式
当条件表达式中同层次上出现由连接词OR连接的表达式,并且OR所连接的表达式的左表达式相同且谓词符号也相同时,那么可以将这些表达式合并为一个右表达式用ANY来描述的表达式。例:
可改写为:
2.2.2 将ANY或ALL转化为简单的比较表达式
当谓词的右表达式为ANY或ALL的形式,并且ANY(ALL)包含的各表达式均有固定值,并且可以比较大小,则可根据谓词符号(仅限于比较大小的操作符)将ANY(ALL)重写为简单的比较表达式。例:
x>ANY(100,200,300) 可改写为:x>100;
x>ALL(100,200,300) 可改写为:x>300
2.2.3 将BETWEEN…AND转化为AND连接的表达式
可以把由BETWEEN expr1 AND expr2的形式重写为用AND连接的两个表达式,效率往往有一定的提高。例:
可改写为:
2.2.4 将IN谓词表达式转换为OR连接的谓词表达式
例:年龄IN(20,30,40)
可写为:年龄=20 OR年龄=30 OR年龄=40
以上提到的4类谓词重写规则均有其特定的条件,在条件满足的情况下才可以使用。对于简单谓词的重写,每条规则提高的效率可能不太明显,但如果查询语句的WHERE条件同时使用多条规则进行重写时,效率的提高将非常可观。
2.3 子查询合并
子查询合并是将某些特定的子查询重写为等价的多个表的连接操作。子查询合并的作用在于能使查询语句的层次尽可能地减少,从而可提高查询的效率。子查询合并的一般规则为:
(1)如果外层查询的结果没有重复,即SELECT子句中包含主码,则可以合并其子查询,并且合并后的SELECT子句前应加上DISTINCT标志;
(2)如果外层查询的SELECT子句中有DISTINCT标志,那么可以直接进行子查询合并;
(3)如果内部子查询结果没有重复元组,则可以合并。
例:查询选修002号课程的学生基本信息。
用子查询的方法如下所示,例:
可改写为:
2.4 用集合运算来代替逻辑运算
0R在嵌套查询中,表的顺序存取对查询效率可能产生致命的影响,避免这种情况的方法就是对连接的列进行索引。例如两个表:student(sno,sname,age)和sc(sno,cno,score)。如果两个表要做连接,就要在“sno”这个连接字段上建立索引。还可以使用并集来避免顺序存取,尽管在所有检查列上都有索引,但某些形式的WHERE子句强迫优化器使用顺序存取。下面的查询将强迫对student表执行顺序操作:
OR xb=′计算机系′
虽然在sno和系别名上都建有索引,但是在上面的语句中优化器还是使用顺序存取的方法扫描整个表因为这个语句要检索的是分离的行的集合,所以应该改为如下语句:
UNION SELECT*FROM student WHERE xb=′计算机系′
2.5 多表连接优化
最能体现查询复杂性的就是多表连接,多表连接操作往往要耗费大量的CPU时间和内存,因此多表连接查询性能优化往往是SQL优化的重点与难点[3]。
2.5.1 充分利用连接条件
在某种情况下,两个表之间可能不只一个的连接条件,这时在WHERE子句中将连接条件完整的写上,有可能大大提高查询速度。例:
这里,第二句将比第一句执行快得多。
2.5.2 先筛选后连接
当查询多个数据表时,要先过滤后再连接。例:
它们的执行效率相差很大。第一个查询语句首先将两个数据表按照用户ID进行连接,然后再将符合条件的记录筛选。由于两个数据表进行连接时记录有些是以后还要筛选掉的,这显然会占用更多的时间,且多个数据表连接是笛卡儿积运算,消耗的时间会随着记录个数的增加很快地增长。第二个查询语句克服了这个缺点,首先筛选出符合条件的记录,减少了进行连接的记录个数,然后再执行连接查询,大大提高了查询效率。
3 结语
查询优化要抓住关键问题,对于数据库应用程序,重点在于如何提高SQL的执行效率。在数据库的开发和维护过程中,查询的优化设计可以提高系统性能,对于数据量大的数据库系统尤为重要。以上介绍的几种优化策略使查询在时间和空间上提高了系统的性能,在一定程度上提高了查询效率。
参考文献
[1]王珊,萨师煊.数据库系统概论[M].4版.北京:高等教育出版社,2006.
[2]丁宝康,董健全.数据库实用教程[M].2版.北京:清华大学出版社,2003.
[3]范剑波,张晓云.网络数据库技术与应用[M].西安:西安电子科技大学出版社,2004.
[4]刘志成,彭勇.数据库系统原理与应用[M].北京:机械工业出版社,2007.
[5]罗运模.SQL Server数据库系统基础[M].北京:高等教育出版社,2006.
[6]宋瀚涛,李新社.数据库编程与应用[M].北京:电子工业出版社,1998.
[7]史嘉权.数据库系统概论[M].北京:清华大学出版社,2006.
[8]马李明,王守桃,徐艳蕾.SQL语句的优化在提高数据查询中的应用[J].电脑知识与技术,2008(20):200,223.
查询优化 篇5
简述：高考成绩查询2012高考成绩查询高考成绩查询2012高考成绩查询电话查询高考成绩网上查询方式，各省市高考成绩查询，2012各省市高考成绩查询，2012各省高考录取分数线，高考成绩查询如下：省市查分时间查分方式分……
高考成绩查询2012高考成绩查询高考成绩查询2012高考成绩查询电话查询高考成绩网上查询方式，各省市高考成绩查询，2012各省市高考成绩查询，2012各省高考录取分数线，高考成绩查询如下：
省市查分时间查分方式分数线
河南2012高考分数线
河南高考成绩查询：网上免费查询：考生可登录河南省教育厅网站(www.haedu.gov.cn)、河南省招生办公室网站(http:/www.heao.gov.cn)、河南招生考试信息网(http:/www.heao.com.cn)、河南省普通高校招生考生服务平台(http:/pzwb.heao.gov.cn)查询。
电话查询：考生可拨打声讯电话(9601166)查询，全省统一号码，本地电话直接拨打，电信部门只收市话费，免收信息费。
现场查询：考生可到县(市、区)招办招生考试综合服务大厅现场免费查询。
2012高考成绩查询
河南6月24日(已出)网上查询：考生可登录河南省教育厅网站、河南省招生办公室网站、河南招生考试信息网查询……
北京6月23日(已出)北京高考成绩网上查询开通…
江西6月23日(已出)江西20高考成绩查询开通…
山东6月24日(已出)考生可拨打声讯电话或登录网站两种方式进行查询……
湖南6月25日(已出)通过“湖南招生考试信息港”网站免费为考生提供成绩查询和高考录取信息查询服务……
辽宁6月25日(已出)考生可登陆“辽宁招生考试之窗”网站查询中心免费查询……
四川6月22日(已出)6月22日晚公布高考成绩……
天津6月23日(已出)考生可通过招考资讯网)查询……
河北6月22日(已出)河北2012年高考成绩网上查询开通……
甘肃6月21日(已出)甘肃2012年高考成绩查询开始……
山西6月25日(已出)可通过“山西招生考试网”……
上海6月26日20点阅卷预计6月中下旬结束，6月26日公布成绩……
广东6月26日(已出)考生可通过网站、电话和短信等方式查询自己的考试成绩……
黑龙江6月24日(已出)具体查询渠道为三种……查询历年分数线
吉林6月21日(已出)可通过吉林省招生委员会办公室招生信息网、吉林省教育信息网、吉林教育电视台信息网免费查询高考成绩……
福建6月25日(已出)考生本人可登录省教育考试院网站查询……
海南6月25日(已出)考生可登录省考试局网站查询本人的成绩……
内蒙古6月23日(已出)内蒙古2012年高考成绩查询开通……
浙江6月22日(已出)考生可凭准考证号和姓名登录浙江省教育考试网(www.zjzs.net)或浙江在线(www.zjol.com.cn)，查询自己的考试成绩……
新疆6月25日(已出)登录新疆教育信息网等网站可免费查询…
贵州6月21日(已出)凭准考证上的`准考证号和密码登录网上填报志愿系统网站查询成绩和录取信息……
广西6月21日(已出)6月21日晚10时起，考生可按规定方式查询广西2012年普通高考成绩…
湖北6月25日(已出)6月25日，省教育考试院将向考生和社会发放成绩……
江苏6月24日(已出)6月24日晚江苏高考分数将揭晓…
重庆6月23日(已出)考生可以登录重庆市教育考试院网站或重庆招考信息网查询……
陕西6月25日(已出)陕西2012年高考成绩查询开通……查询历年分数线
云南6月23日(已出)云南2012年高考成绩查询已开通……查询历年分数线
青海6月25日(已出)由省招办下发到考区招办，并在“青海招考信息网”上公布……
宁夏6月20日(已出)宁夏2012年高考成绩查询已经开通…
安徽6月24日(已出)今年高考各批次分数线及考生成绩在6月24日对外公布，考生可自行上网查询……
西藏6月26日(已出)西藏2012年高考成绩查询开通……
各地高考成绩公布时间及志愿填报方式
2012年全国高考结束后，各地陆续发布成绩查询时间及志愿填报方式。本网梳理如下，供各位考生及家长参考。
2012年各地高考成绩公布时间及志愿填报方式
省(区市)查分时间志愿填报时间
北京2012高考分数线
北京
6月23日
5月12日8时至17日24时;专科志愿填报定于7月28日8时至29日24时进行。
北京历届高考录取分数线
2012河北高考分数线：
(一)文史类
1.本科一批：572分
2.本科二批：529分
3.本科三批：425分
4.专科批：200分
(二)理工类
1.本科一批：564分
2.本科二批：509分
3.本科三批：340分
4.专科批：200分
(三)体育(文)
1.本科提前批：文化325分，专业285分
2.本科三批：文化320分，专业275分
3.专科提前批：文化170分，专业260分
(四)体育(理)
1.本科提前批：文化280分，专业285分
2.本科三批：文化270分，专业275分
3.专科提前批：文化170分，专业260分。
天津
预计6月23日
高考考生填报志愿于公布成绩后进行。6月24日至6月28日12时，符合规定分数范围的考生填报本科二批及以上院校志愿(6月24日至6月26日12时，艺术类考生、体育类考生分别填报艺术类本科院校志愿和体育类本科院校志愿)。
7月27日至7月30日12时，考生填报本科三批录取院校志愿和高职高专录取院校志愿(含艺术类高职高专录取院校、体育类高职高专录取院校、高职高专提前录取院校、高职高专录取院校)
上海
6月26日
5月14日至19日网上填报2012年上海秋季高考志愿从今天起开始填报，将至5月19日结束。今年上海市“一本”、“二本”征求志愿将增至10个。
广东
6月26日
考生填报志愿在6月27至7月3日进行，今年广东省继续实行高校招生平行志愿投档录取模式，第一批填报志愿的考生为美术、音乐、体育类考生，及第一分数段(分数段的划分另行公布)的文、理科考生，填报时间为6月27日-6月30日
山东
6月25日前
今年山东高考志愿6月29日开始填报，与去年相比，今年本科一批增设了征集志愿，所以今年填报志愿次数由去年的分7次填报，调整为分8次填报。
四川
6月22日
今年全省仍实行网上填报志愿。填报志愿时间(不含艺术、体育类专业)为考生成绩通知之后，6月28日12:00前填报，其中提前批志愿在6月24日17:00以前填报。
福建
6月24日
知分知线后填报志愿(包括征求志愿)。填报均通过计算机网络进行。考生应在规定的时间内自行登录福建省教育考试院网站填报志愿，逾期不予补报。
河南
6月25日
网上填报志愿分三次进行：第一次在6月20日-28日，填报提前批、专项计划本科批和专升本志愿;第二次在6月30日-7月4日，填报本科一批、本科二批和对口生志愿;第三次在7月6-10日，填报本科三批、专项计划专科批、高职高专一批和高职高专二批志愿。
河北
6月23日左右
按计划2012年6月24日18时至27日18时填报本科二批及以前的各批次和对口本科批的第一志愿;在本科二批二志愿征集时，填报本科三批的第一志愿;在本科三批二志愿征集时，填报专科提前批、专科批及对口专科批第一志愿。
查询优化 篇6
关键词:神经网络 数据库 查询优化 应用
1 神经网络简介
神经网络是大脑的一个组成部分,人工神经网络模型是基于生物学中的神经网络的基本原理建立的。它是以大脑作为研究基础的,其目的在于模拟大脑的某些方面的机理,实现大脑某些方面的功能,因此,进行神经网络实现技术研究的目的,也即进行神经计算机研究的目的不是寻求一种传统计算机的替代物,而是要开垦那些人类“唾手可得”,而传统计算方式却“举步维艰”的领域。
从数学的角度可以归纳为以下几个基础属性:
1.1.1 非线性:人工神经元可以表述为激活和抑制两种基本状态,这就是一种非线性关系。
1.1.2 非局域性:人工神经网络系统是以人工神经元之间的相互作用表现信息的处理和存储能人。系统的整体行为不仅取决于单个神经元的状态,而且取决于它们之间的相互作用,用此来模拟大脑的非局域性。
1.1.3 非凸性:非凸性是指人工神经网络的演化过程在满足一定条件下取决于某特定函数,而且该函数具有多个稳定点,这将导致在不同边界条件下得到不同的结果,这就是系统演变的多样性。
1.1.4 非定常性:表现在人工神经网络具有自组织、自适应和自学习能力。
数据库系统,特别是大型数据库系统,完全可以看作是分布式系统。
在分布系统论中假定了分布系统中的大量处理单元都是自律要素,并且通过自律要素间的相互作用体现整体性能相信息处理能力。自律要素的处理能力可以是非常复杂,也可能异常简单。相对而言,在人工神经网络模型中,一般假设神经元是一个非常简单的处理单元.每个单元向其它单元发送兴奋性或抑制性信号。单元表示可能存在的假设,单元之间的相互作用则表示单元之间存在的约束。这些单元的稳定激活模式就是问题的解。
我的观点是,在数据库查询优化领域,作为模拟大脑的神经计算方式具有如下的重要特点:①在短时间内寻找好的,但不一定是最好的解答。②由大量的简单的处理单元协同处理问题。③在模糊、不完整或冗余,甚至矛盾的数据基础上进行问题求解。④容错能力强。
关于以上特点中的第一点,其实这是启发式算法的共同特点之一。启发式算法是这样定义的:一个基于直观或经验构造的算法,在可接受的花费下给出带解决组合优化问题每一个实例的一个可行解,该可行解与最优解的偏离程度不一定事先可以预计。
在某些情况下,特别是实际问题中,最优算法的计算时间使人无法忍受或因问题的难度使其计算时间随问题规模的增加以指数级速度增加,此时只能通过启发式算法求得问题的一个可行解。
神经网络方法是模拟大脑的,所以其输入就是晶枝,处理单元就是神经元,可以进行“抑制”和“兴奋”两类处理,最后通过突触传送给其他的神经元。以下是自然神经网络图(见图1):
以及神经元的数学模型:
2神经网络在数据库查询优化中的具体应用
查询是数据库使用者进行的主要操作之一。在这方面,最初的查询优化方法是试用那些没有坏的影响的方法。大部分的变化,比如增加索引、改变模式或者修改事务的长度都对全局有影响,有时是有害的负面影响。而重写查询使之以更高的速度运行则只有有利的影响。
在查询事务处理中,锁查询优化是一个重要内容,下面结合神经网络思想进行分析。
关于锁查询优化,下面是一些建议:①使用特殊的系统程序来处理长的读操作。②消除不必要的封锁。③根据事务的内容将事务切分成较小的事务。④在应用程序允许的情况下,适当降低隔离级别。⑤选择适当的封锁粒度。⑥只有在数据库很少被访问时才修改有关数据定义的数据。⑦考虑划分。⑧减少访问热点。⑨死锁监测周期的查询优化。
每个建议都可以独立于其他建议来运用,但是仔细的分析会发现,要很好的处理这些建议,神经网络算法的特点似乎很合适。
比如说,在谨慎降低隔离级别的过程中,可以使用简单的单层前向神经网络思想。
低隔离级别是有益的,但也是由风险的,在这个过程中可串行化的价值也在体现当中。
为了确定隔离级别,可以进行相应的试验,可以不断的重复执行一个对所有帐户的余额求和的查询事务以及若干个转帐事务。试验的参数是执行这些转账事务的线程数。
初步试验可以在数据库使用前模拟进行,目的是获得理想的结果参数,包括可串行化的影响,死锁可能性,阻塞可能性,隔离级别等等。
然后构建一个如下的单层前向神经网络:
在单层神经网络中,只有输入层和输出层,输出层主要通过对输入层的输入数据和同理想输出结果的比较,确定其权数,最后,用确定了权数的神经网络应用到实际问题中。
也就是说,实质上经历了三个阶段,先确定理想结果参数,然后确定权数,最后投入应用。
另外,在减少热点的应用中,有时插入数据的事务都会将每个新的数据项同一个惟一的表示练习起来。当多个插入事务并发执行时,他们必须协调工作以避免将同一个标识联系到不同的数据项上。
一般的,可以通过给数据库建立一个计数器来实现。每个插入事务首先对计数器加1,接着完成它的插入操作和其他操作,最后提交。问题是这个计数器很可能会成为瓶颈,因为根据两阶段封锁机制,事务只有提交时才可以释放它在计数器上的锁。
在这里可以用一个采用非线性激活函数的前向神经网络。比如将激活函数设定为符号函数,阀值为0,这样一个系统是可以识别XOR问题的,他的分类识别问题很强,而且简单,完全可以应用在协调上述工作上。
从以上例子可以看出,神经网络和数据库优化的主要切入点在于学习和识别,在查询优化过程中遇到识别问题的地方,都可以试试神经网络算法。而学习的能力,则完全可以应用于一些繁琐的维护,是系统尽可能的拥有自维护能力。
参考文献:
[1]高红云,王丽颖,汪再秋.分布式数据库查询优化分析及实例[J].软件导刊.2008.(02).
查询优化 篇7
XML数据是自描述的,是半结构化的数据,数据具有完整的嵌套层次;数据是有序的。[1]XML查询是以长路径表达式为查询的路径复杂,包含分支路径的核心语句;嵌套的查询表达,查询表达式中加入编程语言的嵌套和条件判断思想;路径中包含不确定因素,这在之前的查询需求中未出现过;查询对象和返回结果类型不确定。由于现有的面向对象数据库无法处理XML查询中的路径不确定情况,因此我们要寻求能适应XML查询需要的优化。
2 相关知识
2.1 Xpath
XML可以看作是点标记的有向树。Xpath是XML树中导航查询的基本机制。Xpath支持丰富的路径查询特性,给出了Xpath中常见的操作符号语义:'/'。表示数据节点之间的父子关系,"//"表示节点之间的祖孙关系,'[]'表示路径之间的条件关系,'@'表XML元素的属性,'*'表示任意的数据元素,另外支持在路径表达式中定义逻辑表达式,包括:。
2.2 XML查询优化研究
1)查询代数标准
关系数据库统治数据管理领域主要源于描述性查询语言SQL及其运行基础关系代数,关系代数的目的是给出明确的查询语义,用于支持查询优化。[2]XML数据模型本身具有的半结构化特点,XML查询语言中的不确定性,这些亟待完善。
2)代价估计
在XML模型中,数据是有序的,数据聚集的方式不定,每个数据的大小相差悬殊,中间结果大小与I/O次数之间的对应关系没有明显的规律,这就要求不能简单地沿用传统的代价计算方法,以便提高代价估计。
3)统计信息
由于缺乏足够的统计信息造成估计与实际情况的误差也是XML要优化的一个方面XML数据本身缺乏模式的支持,因此要精确类似树状结构的树叶上的XML数据中的数值,把对结构的统计信息和对值的统计信息结合到一起。
2.3 XML验证机制与模式
XML文档都必须是“格式良好的”,还应当符合语义方面的规范。对XML文档有效性的检查称为对XML的“验证”。[3]
XML规范的验证机制中主要有两种模式:DTD[7]和XML Schema。XML Schema与DTD一样,也是XML验证机制的一种,用一套预先规定的XML元素和属性创建的,这些元素和属性定义了文档的结构和内容模式。
3 Xpath查询优化的实现
3.1 问题分析
在Xpath中,谓词有两个分支b和//c,这里b相当于/b,//a的关系是父子关系,而//c中的//是表示子孙节点的轴,表示节点c是节点a的孩子或者孙子这种不确定的情况。相应的节点c与作为节点a的孩子的节点b之间的关系也不确定:节点c可能是节点a的兄弟或者子孙。因此笔者考虑/bznd//c与/b//c这两种情况,这是//轴的不确定语义引起的,这使得在构造转换函数时会增加中间状态,降低转换效率。
在多个Xpath表达式的情况下,状态的不确定使得很多时候无法合并相同分支。XPath表达式中出现的“*”是一个通配符,即表示下个字符只要是定义中合法的字符都匹配,同样代表不确定的语意,但它比的简单不涉及祖孙多代之间的不确定语意,处理方法同“//”,所以本章我们重点讲述了对的处理,对“*”的处理也可使用同样的方法。使Xpath表达式在解析前进行确定化,可以借助XML的验证机制,用文档的模式信息来进行约束及确定化。
3.2 基于XMLSchema的Xpath的优化实现
Xpath中出现的“*”和“//”路径操作符号将导致路径匹配过程中的不确定性,在执行过程中产生大量回溯。由于目前XML大多遵从DTD约束,,所以可以考虑利用XML Schema中的结构约束信息来减少Xpath中的不确定因素,提高查询执行效率。
给定XML文档的XML Schema信息,以及要查询的Xpath。根据XML Schema约束来重写Xpath,使得重写后的Xpath中的"/"和"*"尽可能的减少,达到确定化的目的。同时重写过的XPath和原来的XPath查询结果相同。
XML Schema也是一个XML文件,遵守XML文档所有语法,一般来说XML文档的层次结构可以用树模型来表达,[5]但考虑到XML文档中可以出现相同的元素,XMLSchema可以递归定义,所以该文利用有向图加权图表示XMLSchema和Xpath结构,并且利用XML Schema的有向图和Xpath有向图的乘积来进行优化。
3.2.1 有向图
图(Graph)是一种复杂的非线性结构。[4]本文就是借用图的有向性
定义1:一个有向图G是一个二元组,即G=
定义2:一个带标志的有向图G是一个三元组即G=
定义3:用
3.2.2 优化
定义10有向图的乘积:
XML Schema有向图G1=
G3=
其中V3=V1×V2,E3=E1×E2,W3=W1∩W2且
3.3 算法实现
有向图的乘积
输入:两个有向图S[][]M[][]
输出:乘积有向图SM[][]
4 结束语
根据有向加权乘积图来用XML Schema来约束XPath是可以达到优化的,该文给出了切实可行的优化算法,使XPath约束下的不确定性尽量减少,但未来还有很多工作要做,比如侧重于自动机技术完成Xpath优化,即利用自动机技术来对Xpath建模,提高查询效率、优化查询模型是研究的主要方向。
摘要：该文分析Xpath表达式中出现“★”(任意匹配字符)和“//”(子孙轴)对查询效率的影响,提出用XMLSchema对Xpath表达式进行约束来解决问题,给出实现的核心算法。
关键词：XML,Xpath,优化,算法实现
参考文献
[1]蒋宗礼,姜守旭.形式语言与自动机理论[M].北京:清华大学出版社,2003.
[2]张尧学,方存好.主动服务:概念、结构与实现[M].北京:科学出版社,2005.
[3]张婷,常致全,肖厚新.XPath语义特性及其对XML数据操作的应用研究[J].信息技术,2006,30(5).
[4]吕建华,王国仁,于戈.XML数据的路径表达式查询优化技术[J].软件学报,2003,14(9).
[5]朱战立.数据结构[M].西安:西安电子科技大学出版社,2001.
[6]Georg G,Christoph K,Reinhard P.Efficient algorithms for processing XPath queries.[J]In:Stéphane B,Akmal B.eds.Proc.of the VLDB2002.Heidelberg:Springer-Verlag,2002.
数据库查询优化方法研究 篇8
一、基于索引的优化
数据库的优化方法多种多样, 不同的方法对提高数据库查询效率也不相同。
索引作为数据库中的重要数据结构, 它的根本目的就是为了提高查询的效率。而优化查询的重要方法就是建立索引, 建立适合关系数据库系统的索引, 这样就可以避免表扫描, 并减少了因为查询而造成的输入输出开销, 有效提高数据的查询速度, 优化了数据库性能。
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语句中这个现象被隐藏了, 这样就使得查询中进行了大量的非顺序页查询, 降低了查询速度, 对于这个现象还没有很好的解决方法, 只能依赖于数据库的排序能力来替代非顺序的存取。
四、结论
关系数据库查询优化策略研究 篇9
目前, 随着信息化的不断发展, 数据库作为信息管理系统的后台, 广泛应用于各企事业单位[1], 主要负责信息的处理和存储, 有着举足轻重的地位。据调查, 大部分数据库在应用过程中常会出现延迟、等待处理时间长等问题, 这都可以归结为数据库的效率问题。在数据库对信息的处理中, 以查询所占的比例最大, 那么查询的效率将是数据库信息处理效率的关键所在。良好的查询优化策略, 将大幅提高数据库效率, 例如一些商业海量数据库, 某些原本需要执行数十分钟, 甚至1个小时的查询, 在适当的优化策略下, 执行时间可缩短为几分钟。如何根据实际情况制定适合的查询优化策略, 也正是本文的切入点。本文将通过分析数据库查询效率低的原因, 结合数据库理论知识、数据库应用的经验, 阐述数据库查询优化的策略。
2 影响数据库查询效率的因素分析
影响数据库查询效率的因素有很多, 可简单归纳为以下方面:
2.1 硬件性能方面
这里的硬件主要指数据库服务器, 由一台或多台主机和DBMS (数据库系统管理软件) 共同构成。“工欲善其事, 必先利其器”, 数据库系统服务器的硬件等级, 服务器的相关设置, 直接影响数据库的查询效率。
2.2 查询方案方面
现代的关系数据库的查询以关系代数为理论基础, SQL (Structured Query Language) 语言为手段完成和数据库的通信。用户编写SQL语句, DBMS (数据库系统管理软件) 编译并结合索引等数据库对象执行SQL语句, 返回查询结果实现用户对数据库的查询操作[2]。高效的查询方案可以将数据库的查询效率提高10倍以上, 海量数据更为明显。很多程序员、数据库操作员却并未认识到这点, 以为写出SQL语句能实现查询功能就可以了。
3 查询优化策略研究
数据库的查询优化有多种途径, 这里根据影响数据库查询效率的因素, 分别从硬件性能方面和查询方案两个角度来谈数据库查询优化策略。
3.1 基于硬件性能的查询优化
3.1.1 服务器硬件优化
提高服务器的工作效率, 升级硬件是最直接、有效的一个方法。针对数据库服务器的特点, 硬件升级时应考虑下列内容:
1) 加大内存
对于数据库服务器性能来说, 内存是最重要的因素。因为访问内存中的数据要比访问磁盘中的快, 所以可以通过加大内存, 把更多的数据保存在内存缓冲区, 从而减少磁盘的I/O, 提高数据库效率。
2) 配置多处理器
多处理器数据库系统中, 每个处理器可以运行一个事务, 实现多个事务真正意义上的并行运行, 也可以实现更加复杂的并发机制, 如果不考虑资金的问题是最理想的并发方式。
3) 配置高效硬盘
从磁盘读取数据的时候, 高转速的磁盘可以减少等待时间, 提高相应速度。另外, 可采用磁盘陈列, 优化磁盘的I/O分配使之均衡, 减少资源竞争, 达到提高数据库效率的目的。
3.1.2 服务器设置优化
1) 调整操作系统
服务器的运行离不开操作系统, 操作系统的性能直接影响着服务器的性能。
可通过操作系统规划使数据库服务器占有系统资源最大化, 设置合适虚拟内存的比例, 设置服务器进程优先级等手段提高数据库效率。
2) 调整服务器的缓冲区
数据在内存中的访问速度要高于硬盘中的访问速度, 所以可以通过相应参数设置服务器的缓冲区容量, 让数据和索引更长时间停留在内存中, 减少硬盘I/O, 提高数据库效率, 下面以Oracle为例, 介绍缓冲区的调整。
系统全局域SGA (System Global Area) 是Oracle数据库存放系统信息的内存区域, 是实例Oracle Instance的基本组成部分, 在实例启动时分配。它主要由数据高速缓冲区、日志缓冲区、共享池三部分组成。SGA存在的意义就是把数据放在内存中快速存取, 因此SGA要尽可能都进入内存但不要超过内存的容量, 否则会发生磁盘和内存的页面交换, 反而影响了效率。可以通过语句SHOW SGA
查看SGA内存分配的结构和大小。
数据高速缓冲区的大小应该根据该缓冲区的命中率来调整, 命中率高说明该缓冲区缓存够用, 性能良好。命中率是通过下面公式来计算的:高缓区合中率=1- (physical reads/ (db blockgets+consistentgets) )
公式中涉及的参数是Oracle运行时统计的数据存取情况, 放在V$SYSSTAT表中。physical reads是磁盘文件存取总数, db block gets是数据请求总数, consistent gets是内存缓冲区能够满足的请求总数。可以通过下面的语句查询这几个参数, 如图1。如果命中率低于85%, 将影响数据存取的效率, 可以通过增大初始化参数db_block_buffers的值 (它的最大值为65535) , 来增加高速缓冲区的容量。
共享池由库缓冲区和数据字典缓冲区组成, 它们的大小应根据缓冲区的不命中率来调整。库缓冲区的不命中率应该接近于0, 数据字典缓冲区的不命中率应该低于10%, 否则会影响数据存取效率。它们的不命中率公式如下:
可通过下面语句查询相应的参数, 如图2。如果不命中率过高, 可以通过字典区不合中率=错误请求数sum (getmisses) /相应项请求数sum (gets) 调整初始化参数shared_pool_size来重新调整分配给共享池的内存容量。
3.2 基于查询方案的优化
3.2.1 关系代数的等价变换优化
等价关系代数优化是查询优化的理论基础和前提。关系代数表达式等价主要是指用同样的关系实例代替两个表达式中相应关系时所得到的结果是一样的, 也就是指得到相同的属性集和相同的元组集[3]。等价关系代数优化就是找出等价的关系代数表达式, 从中选出执行效率最高的一个, 并以此为基础写出相应的SQL语句。
常用的等价关系代数规则如表1所示。
注释:E1、E2、E3是关系代数表达式, A1、A2...An, B1、B2...Bm是属性, F、F1、F2、F3是条件表达式
从查询优化的角度分析, 规则1、2的等价变换不会对查询效率产生影响, 而规则3-10的等价变换的查询效率则有所不同。经总结, 等价关系代数优化应遵循以下原则:
1) 根据情况尽量将选择、投影操作提前, 缩小关系的范围
2) 根据情况尽量将同一关系上的选择、投影操作一起进行, 避免关系的重复扫描。
3) 根据情况将选择或投影和连接结合起来进行, 以减少关系范围
3.2.2 合理的创建索引
索引是数据库中重要的数据结构, 它就像书的目录一样可以辅助快捷的访问数据库中的数据, 而不需要对数据库表进行遍历。索引的使用是由DBMS (数据库管理系统) 操作的, 作为数据库的设计者或操作人员, 关注的应该是如何创建合理的索引, 合理的索引设计要建立在对各种查询的分析和预测上。索引创建的不合理, 会有相反的效果。通常创建索引时, 要遵循以下原则:
1) 在频繁操作的列上建立索引。这样的列指的是多表查询时的表连接属性, 分组GROUP BY, 排序ORDER BY的依据属性。常用于分组、排序的列可以考虑建立聚集索引 (clustered index) 。
2) 在条件表达式中经常用到的取值范围大的列上建立检索, 取值范围低的列上不要建立索引。如属性“婚否”的取值范围只有“是”与“否”两个不同值, 就没必要建立索引。建立索引反而会降低更新速度。
3) 如果经常多列同时存取, 并且每一列都含有重复的值, 可以考虑建立组合索引 (compound index) ;
4) 对于不经常作为关键字查询的列则少创建或者不创建索引:对于频繁删改的表, 尽量少创建索引。
3.2.3 合理使用存储过程
存储过程 (Stored Procedure) 是一组具有特定功能的由流控制和SQL语句编写的程序块, 经编译和优化后存储在数据库服务器中, 具有灵活、性能高的特点。在数据库的应用中, 可以将数据库中常用的复杂查询操作写在存储过程中, 查询的时候调用相应过程就可以了。常规的SQL语句数据库系统是要编译后才可以执行的, 存储过程是经过编译和优化的, 用户在调用它进行查询的时候节省了编译时间;另外, 存储过程是存放在数据库中的, 这样查询的时候直接调用减少了系统的I/O, 提高了查询效率。可能存储过程每一次调用节省的时间很少, 但是如果对于多用户访问的海量数据库, 将是一个很大的性能提升。
3.2.4 合理编写SQL语句, 避免对表的顺序遍历
1) 尽量避免在SQL语句中对属性进行NULL值的判断, 防止DBMS将放弃索引进行全表遍历。如下面的查询SELECT NAME FROM EMP WHERE SAL IS NULL可进行如下优化, 将EMP表的SAL属性默认值设置为0, 让该属性没有NULL值, 查询语句变为SELECT NAME FROM EMP WHERE SAL=0
2) 尽量避免在SQL语句中使用OR作为查询条件的连接词, 防止DBMS跳过索引全表遍历。如下面的查询SELECT NAMEFROM EMP WHERE SAL=1000 OR
SAL=2000可以进行如下优化, 用UNION ALL代替OR, 查询语句变为SELECT NAME FROM EMP WHERE SAL=1000 UNIONALL SELECT NAME FROM EMP WHERE SAL=2000
3) 尽量避免在SQL语句中使用IN、<>或NOT关键字, 它们都会使DBMS放弃索引, 全表遍历。IN谓词可以用EXISTS谓词替代, 因为IN谓词引导的子查询返回是一个结果集, 而EXIXTS谓词引导的子查询返回的是’TRUE’或‘FALSE’, 然后子查询的结果再作为条件参与父查询, 显然EXISTS谓词引导子查询的效率会更高。如下面的查询SELECT SNAME FROM S WHERE SNO IN
(SELECT SNO FROM SC WHERE GRADE>80) 可优化为SELECT SNAME FROM S WHERE
EXISTS (SELECT 1 FROM SC WHERE SC.SNO=S.SNO AND GRADE>80) 。
4) 尽量避免在WHERE字句中对属性进行公式、函数操作, 如下面的查询SELECT NAME FROM EMP WHERE SAL*3=3000可以优化为SELECT NAME FROM EMP WHERE SAL=3000/3;SELECT JOB FROM EMP WHERE substring (name, 1, 3) ='smt'可以优化为SELECT JOB FROM EMP WHERE NAME LIKE‘smt%’
5) 尽量避免对表进行全属性SELECT*查询, 查询要精确写每个属性, 全属性也不例外。
3.2.5 合理运用查询优化器
查询优化器是数据库系统的一个组件, 简单的说, 它会根据已有的索引和查询信息的统计, 对SQL语句进行优化, 得到它认为性能最好的, 查询最高效的执行方案。通常, 查询优化器所作的工作用户看不到, 默认执行。但是, 有些时候我们也可以根据实际情况通过参数设置查询优化器, 让它更高效的运行。
以Oracle为例, 查询优化器认为性能最优的标准有两点, 一是Best throughput, 即从SQL开始执行到结束的时间最短, 二是Bes Response time, 即从SQL开始执行到返回第一条记录的时间最短。两个标准可以根据我们的需要设置参数Optimizer_mode来确定它们的优先级。设置参数为All_Rows表示希望以Best throughput的方式来优化, 设置参数为First_Rows_N表示希望以Best Response time的方式来优化。
4 结论
在大型数据库广泛应用的时代, 数据库查询优化已成为一门关键技术, 运用合理, 可以大幅提升数据库系统的效率[5]。提升硬件方面的优化是要衡量开销的, 使用优化器等软件优化仅是常规的优化, 在实际的应用中, 我们最需要关注和探索的是发掘现有服务器的潜能, 对数据查询方案作有效的分析并整理出高效率的数据查询方案。
参考文献
[1]杨小艳.Oracle数据库查询优化方法研究[J].计算机与现代化, 2008 (4) :4-7.
[2]李俊民.精通SQL-结构化查询语言详解[M].北京:人民邮电出版社.2008 (8) .
[3]梁志宏等.等价关系代数查询优化方法的研究[J].山西师范大学学报, 2004 (18) :34-38.
[4]盖国强等.Oracle数据库性能优化[M].北京:人民邮电出版社, 2005.
浅谈数据库查询优化技术 篇10
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) .
分布式数据库查询优化分析 篇11
1 分布式数据库的组成
分布式数据库属于比较复杂的一个计算机系统, 关于这个系统主要包括下面几个组成部分。
1.1 硬件
硬件是分布式数据库完成其功能的物质条件, 分布式数据库要实现其预定的目标, 必然要依赖对应的硬件, 这里的硬件环境是分布的。硬件包括CPU和内存以及外存等, 不同站点选择其硬件要能够与本地的应用规模相适应, 同时也需要充分考虑全局应用规模, 要根据站点实际的需要来选择最佳的通信设备。
1.2 软件
分布式数据库在具备硬件条件以后还需要对应的软件来辅助其功能的实现, 每一个站点需要配备一定的操作系统还有数据库管理系统, 这样站点才能满足其自身的需要。为更好的处理和完成全局事务, 高层的分布式数据库管理系统也是必不可少的。只有将软件和硬件有效的结合起来, 才能真正的发挥其作用。
1.3 数据
数据是分布式数据库基本的组成部分, 根据其存放形式可以将数据分为局部数据与全局数据两大类。局部数据是以局部数据库的形式存放, 全局数据是以全局数据库的形式存放。
1.4 人员
分布式数据库需要很多的人员, 只有多层次的才能满足分布式数据库需要, 各个环节都需要人员来完成, 各个层次的人员要进行分工合作, 通过共同的努力来实现数据库查询的需要。
2 分布式数据库具有的特征
分布式数据库属于数据集合, 从物理的角度上来看分布式数据库是分散的, 但是从逻辑上来看分布式数据库又是统一的。尽管分布式数据库将各自数据分布在多个站点, 但是其是基于一个统一的逻辑框架上面的。分布式数据库具有这么几个方面的特征:
2.1 数据分布性
分布式数据库系统里面的数据分散被分散在各个站点上面, 各个站点之间是通过计算机网络来进行连接的, 因此分布式数据库的数据具有分布性的特征。
2.2 逻辑关联性
尽管分布式数据库的数据分布在不同的站点, 但是其从逻辑上来看属于是一个统一的整体, 所有的数据都存在于一个统一的逻辑框架上面。
2.3 站点自治性
分布式数据库的不同站点属于独立的数据库系统, 每一个站点都有属于其自身的数据库, 也有属于自身的软件和硬件, 因此其具有非常强的自治性。
3 分布式数据库查询的层次结构
分布式数据库查询处理有查询分解、数据本地化、全局优化、局部优化四个层次。
4 分布式数据库查询优化办法
关于对分布式数据库查询优化可以采取的方式可以从下面几个具体方面来进行。
4.1 优化索引来提升查询速度
数据索引对分布式数据库查询发挥着非常重要的作, 对索引进行优化可以有效的提升查询速度, 使得查询需要的时间大大缩短。对索引进行优化需要遵循这么几个方面的原则:对于没有指定为外键, 但是实际上连接又非常频繁的地方设置索引, 在不常用于连接的字段可以由DBMS自动生成索引;在需要频繁进行排序和分组操作的列设置索引;在排序列数较多时可以设置复合索引。
4.2 避免和简化排序操作
大型数据表如果要是进行排序会对数据库查询速度有着非常大的影响, 为了提高数据库的查询速度, 在可能的情况下要尽可能避免对大型数表进行排序。通过索引根据一定的次数输出这种方法就可以在很大程度上来代替排序操作, 既实现了排序操作的目标, 又对数据查询速度没有太大的影响。索引增加对排序操作的避免有重要的作用, 还可以对数据表进行合并, 使得排序的次数降低, 当然这些操作必须在适当的范围内, 不能因为单纯避免排序而成为一种累赘。在实际中有时候排序操作是无法避免的, 如果要是排序操作无法避免, 那么要采取相应的措施来简化排序操作, 可以适当的去缩小排序范围, 适当排序的部分被简化, 那么对数据库查询速度的影响会降到最低。
4.3 尽量避免顺序存取大型数据表
嵌套查询的顺序存取会对降低数据查询效率, 使得数据查询的速度受到很大的影响, 为了避免分布式数据库查询效率受到影响, 要尽量避免顺序存取大型数据表。通过对存在连接的列建立索引以及利用索引路径处理查询的办法来避免顺序存取大型数据表, 这样就可以大大降低嵌套查询的顺序存取造成的影响。
4.4 构建临时表
对数据表的子集重新排序, 并且构建临时数据表会使得分布式数据库查询效率得到有效的提升。
4.5 简化嵌套层次
为提升分布式数据库查询效率, 那些困难的正规表达式和相关子查询要尽量避免, 查询嵌套层次要做到优化, 嵌套层次要尽量的去简化。嵌套层次多的时候就会出现重复操作的现象, 为避免主查询与子查询有不必要的重复, 要尽量减少主查询里面的子查询。
5 结论
计算机与网络技术的发展, 推动着分布式数据库系统也在快速发展。在对分布式数据库进行查询的时候, 因为物理分布的不同会大大增加数据的查询难度。分布式数据库查询优化对数据库的性能高低有直接的影响, 采取不同的查询方式, 其效率有很大的差别, 采取有效的数据库查询方式可以使得查询效率明显提升, 因此本论文提出的优化方式具有很重要的现实意义。
摘要：本文对分布式数据库的基本概念进行阐述以后, 提出了相应的优化方式, 采取这些优化办法会使得分布式数据库查询效率得到有效提升。
关键词：分布式数据库,查询,优化
参考文献
[1]赵荣.分布式数据库查询优化方法[J].科技视界, 2013 (03) .
【查询优化】推荐阅读：
查询及优化08-16
多查询优化11-30
数据库查询优化06-28
查询表达式优化04-01
空间数据查询优化研究01-14
数据库查询优化研究01-17
数据库查询优化方法12-20
数据库的查询优化02-08
关系代数与SQL查询优化的研究06-25
扫一扫微信支付