数据库优化策略分析

数据库优化策略分析（精选10篇）

数据库优化策略分析 第1篇

1、基于范式 (N F) 优化数据库

关系模式规范化的基本思想是消除关系模式中的数据冗余, 消除数据依赖中的不合适的部分, 解决数据插入、删除进发生的异常现象。这就要求关系模式要满足一定的条件。我们把关系模式规范化过程中不同程序的规范化要求设立的不同标准称为范式。

需要符合第三范式, 其原理是所有的非主属性都不函数传递于主属性。第三范式的运用, 不仅避免了由于频繁的数据备份给相关操作带来的不利影响, 而且很好的保护了数据库的各方面性能不受到损害, 使其能够正常的运行。

运用第三范式设计数据库时, 往往力求改变数据库的各方面性能。但是不是分解得越多越好, 因为在查询上, 时间上要浪费得更多。因此, 对于时常要使用的表或者相关数据, 要对其结构及性能进行全面优化和调整。

1.1 采用视图方式

在某些数据量较大的表中, 只有部分数据要求被频繁访问, 对于这种情况我们可以考虑采用视图方式, 将被访问数据进行视图访问。这种方式不仅不用担心磁盘的占有率 (因为视图是一种虚拟表) , 而且在很大程度上确保了数据库的安全性。

1.2 储存派生的数据

某些过程需要经过大量重复的计算, 应当采取相应列的添加方式进行结果储存。

1.3 合理的路径存储

数据库在处理大型数据时, 应考虑其合理的路径存储, 是不是应该考虑单独一个物理盘来存储。

随着范式级别的不断提高, 冗余和更新异常等不合理情况已逐渐消失在关系模式中, 但由于范式级别的不断提高, 目前已经达到5NF, 关系模式进一步分解, 难免会造成表数目的不断增加, 势必会将查询操作复杂化。由于查询的链接操作带来的开销非常大, 关系链接的复杂化不仅会加重数据库系统的压力, 而且还户影响其正常的工作效率, 因此在追求模式规范化的同时, 其方便性和实用性也不能被忽略。在实际应用中, 我们具体问题具体分析, 尽可能的使两者处于一个相对平衡的状态。

2、基于索引优化数据库

索引应用于数据库的主要目的是为了提高数据查询的效率, 而数据库优化查询的重要方法之一是建立索引。建立合适的数据库系统索引, 就可以避免全表扫描, 并减少由于连接查询而造成的各种多余的开销, 有效提高数据库的查询速度, 优化了数据库性能。然而在创建索引时也不由地增加了数据库系统的时间和空间的开销。所以在创建索引时应注意与实际的数据库查询需求相结合, 这样才能真正实现基于索引的优化数据库。

2.1 索引基本概念

索引是一个单独的、物理的数据结构, 它是某个表中一列或若干列值的集合和相应的指向表中物理标识这些值的数据页的逻辑指针清单。

索引提供指向存储在表的指定列中的数据值的指针, 然后根据您指定的排序顺序对这些指针排序。数据库使用索引的方式与您使用书籍中的索引的方式很相似:它搜索索引以找到特定值, 然后顺指针找到包含该值的行。

2.2 创建合适并且高效的索引

创建合适的索引即是对所要创建的索引进行有效的逻辑判断, 使所创建的索引对数据库的工作效率的提高有所帮助。为了实现创建合适的索引, 我们得考虑以下几点要求:在编写SQL程序时, 多注释那些常用且对性能有影响的SQL语句, 以便后来人能更好的理解并利用它, 然后再判断数据库中哪些表中的字段要建立索引;第二, 对数据库中使用次数较多的表, 数据量较大的表, 较经常和其他表进行连接操作的表等, 都要进行特别的关注, 因为这些表上的索引将对我们所编写的SQL语句的性能产生深远的影响。

创建索引一般有以下两个目的:维护被索引列的唯一性和提供快速访问表中数据的策略。大型数据库有两种索引即聚集索引和非聚集索引, 一个没有聚集索引的表是按堆结构存储数据, 所有的数据均添加在表的尾部, 而建立了聚集索引的表, 其数据在物理上会按照聚集索引键的顺序存储, 一个表只允许有一个聚集索引, 因此, 根据B树结构, 可以理解添加任何一种索引均能提高按索引列查询的速度, 但会降低插入、更新、删除操作的性能, 尤其是当填充因子 (Fill Factor) 较大时。所以对索引较多的表进行频繁的插入、更新、删除操作, 建表和索引时因设置较小的填充因子, 以便在各数据页中留下较多的自由空间, 减少页分割及重新组织的工作。

索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题都可以采用索引技术得到解决。作为一条规则, 我通常对逻辑主键使用唯一的成组索引, 对系统键 (作为存储过程) 采用唯一的非成组索引, 对任何外键列[字段]采用非成组索引。不过, 索引就象是盐, 太多了菜就咸了。你得考虑数据库的空间有多大, 表如何进行访问, 还有这些访问是否主要用作读写。

在一般的数据库中, 往往包含存储着海量数据的表, 这时人们在进行查询时, 如果使用全表扫描, 会花费非常多的时间, 同时会导致查询超时这样的错误。通过合理地创建索引, 可以避免全表扫描, 从而获得性能的提升。举个例子来说明:在查询学生信息的数据库中, 一般是通过学生的学号和姓名来查询学生的详细信息, 而没有必要通过学生的电话号码进行查询;在这种情况下, 我们就可以根据学生的学号建立索引, 当有查询请求时, SQL SERVER将查询索引中的学号, 然后根据索引直接提取对应的行, 也就是学生的各种信息, 因此加快了查询的速度。

3、基于查询优化数据库

查询优化是为了查询选择最有效的查询计划的过程。查询优化一方面在关系代数级进行优化, 力图找出与给定表达式等价, 但执行效率更高的一个表达式。查询优化的另一方面涉及查询语句处理策略的选择, 例如SQL语句的合理编写。

3.1 关系代数表达式中的查询优化

关系系统的查询优化是关系数据库管理系统实现的关键技术, 又是关系系统的优点。因为, 用户只要提出“干什么”, 不必指出“怎么干”。在关系代数表达式中, 需要指出若干个关系的操作步骤。问题是怎样做才能保证省时、省空间以及效率高, 这就是查询优化的问题。

需要注意的是, 在关系代数运算中, 笛卡尔积、连接运算最费时间和空间, 空间应采用什么样的策略, 能够节省时间空间, 这就是优化的准则。具体地讲: (1) 提早执行选取运算。对于有选择运算的表达式, 优化的原则是尽可能先执行选择运算的等价表达式, 以得到较小的中间结果, 减少运算量和从外存读块的次数; (2) 合并乘积与其后的选择运算为连接运算。在表达式中, 当乘积运算后面是选择运算时, 应该合并为连接运算, 使选择与乘积一道完成, 以避免做完乘积后, 再对一个大的乘积关系进行选择运算; (3) 将投影运算和其前后的其他运算同时进行, 以避免重复扫描关系; (4) 将投影运算和其前后的二目运算结合起来, 便得没有必要为去掉某些字段再扫描一遍关系; (5) 在执行连接前对关系做适当的预处理, 就能快速地找到要连接的元组。方法有两种:即索引连接法和排序合并法。 (6) 存储公共子表达式。公共子表达式的结果应存于外存 (中间结果) , 这样, 当从外存读出它的时间比计算时间少时, 就可节约操作时间。

3.2 查询优化涉及查询语句 (SQL) 的处理策略

(1) 应尽可能不在where子句中使用“!=”这种不等于的操作符, 因为这样会促使引擎进行全表扫描, 优化器将无法通过合理的索引方式来确定将要查询表的行数, 这将非常浪费查询的时间和空间。

(2) 应尽可能不在where子句中使用“or”操作符, 这样也会导致全表扫描而导致效率差, 如:

select学号from student where座位号=5 or座位号=10

应将上面的查询语句改为:

select学号from student where座位号=5

select学号from student where座位号=10

(3) 应尽量避免使用通配符“%”开头的模糊查询

见如下三个语句:

select学号, 姓名from student where姓名like‘%小%’

select学号, 姓名from studnet where SUBSTING (姓名, 2, 3) =’小’

select学号, 姓名from studnet where姓名like‘小%’

即使姓名字段建有索引, 前两个查询语句依然无法利用索引完成快速查询, 因为引擎要对所有的行进行扫描后才能完成操作;而第三个查询语句能够使用索引来加快查询操作。

(4) 应尽可能不在where子句中对字段进行表达式运算操作 (如加减乘除) , 这也将导致引擎放弃使用索引而进行全表扫描从而降低了查询效率。请看下面三个例子:

1) select学号, 姓名from student where成绩/2=40应改为:

select学号, 姓名from studnet where成绩=40*2

2) select学号, 姓名from studnet where SUBSTRING (学号, 1, 4) =‘1011’

应改为:

select学号, 姓名from studnet where学号like‘1011%’

3) select*from student

where DATEDIFF (yy, dateofbirth, GETDATE () ) >=18

应改为:

就是说:任何对列的操作都将导致表扫描, 它包括数据库函数、计算表达式等, 查询时要注意左边是一个变量, 而右过通常是一组操作表达式。

(5) 应尽可能不在where子句中对字段进行函数操作, 这将导致引擎放弃使用索引而进行全表扫描从而降低了查询效率。如:

select学号from student

where substring (姓名, 1, 3) ='王'--姓名以“王”开头的学号

应改为:

select学号from student where姓名like'王%'

(6) 查询语句中使用exists是一个比较好的编写习惯, 请看下面两个例子:

1) select学号from student where学号in (select学号from score)

改用exists格式:

select学号from student where exists (select学号from score where学号=student.学号)

2) SELECT AVG (A1.j1) FROM A1 WHERE (

改用exists格式:

两者产生相同的结果, 但是后者的效率明显要要高于前者。因为后者不需要全表扫描, 节省了一定的时间, 从而达到优化程序的目的。

(7) 应尽量避免过于频繁创建和删除临时表, 这样可以减少系统表资源的消耗, 从而为别的基本表腾出更多的空间来进行存储与运算。

(8) 在创建或者使用存储过程和触发器的开始处设置“SET NOCOUNT ON”, 在结束时设置“SET NOCOUNT OFF”。这样可以减少向客户端发送信息所造成的时间和空间上的浪费。

(9) 应尽量将大事务操作分解成小事务来操作, 这就是软件工程学里面所讲的采用自顶向下的编程方法, 这样就可以大大提高数据库系统的并发操作能力。

(10) 尽量不使用不兼容的数据类型。例如浮点型和整形、字符型和文本型等是不兼容的。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。例如:

SELECT姓名FROM employees WHERE salary>=70000

在这条查询语句中, 如salary字段是money型 (货币型) 的, 则优化器很难对其进行优化, 因为70000是个整型数。我们应当在书写程序时将整型转化成为钱币型, 而不要等到运行时转化。因为计算机总是比不上我们的大脑, 有时它的自动转化并不会得到我们想要的结果, 这样反而会得不偿失的。

3.3 选择最有效率的表名顺序

SQL的解析器按照从右到左的顺序处理FROM子句中的表名, 因此FROM子句中写在最后的表 (基础表) 将被最先运行处理。如果在FROM子句中有包含多个表的话, 你应该选择记录行最少的表作为基础表。当SQL处理多个表时, 会运用排序及合并的方式连接它们.首先, 扫描第一个表 (FROM子句中最后的那个表) 并对记录进行派序, 然后扫描第二个表 (FROM子句中最后第二个表) , 最后将所有从第二个表中检索出的记录与第一个表中合适记录进行合并.

例如:表1 (T1) 有16, 384条记录

表2 (T2) 有1条记录

选择表2作为基础表 (最好的方法)

select count (*) from T1, T2--执行时间0.96秒

选择表1作为基础表 (不佳的方法)

select count (*) from T2, T1--执行时间26.09秒

如果有3个以上的表连接查询, 那就需要选择交叉表 (intersection table) 作为基础表, 交叉表是指那个被其他表所引用的表.

例如:EMP表描述了LOCATION表和CATEGORY表的交集.

将比下列SQL更有效率

4、结语

数据库访问是影响现代应用程序性能和可伸缩性的一个关键点。虽然框架支持构建数据访问逻辑, 仍然需要对数据访问逻辑投入相当的精力, 以避免种种陷阱和问题。问题之关键是要理解应用程序数据访问层的动态和特性的一切细节。

优化数据库对提高计算机系统的可用性和效率, 具有非常重要的意义, 特别是在数据库设计研发阶段, 对逻辑结构和物理结构进行有效的优化设计, 创建一个规则布局合理的数据库, 能获得最小的系统开销, 能从根本上大大提高应用系统的整体性能, 对于以后的数据库性能调整和利用都有非常大的益处。对数据库的优化, 关系着我们对数据库的应用是否高效。本文在对数据库优化策略分析的基础上提出了部分见解, 有效的提高数据库的应用。

摘要：从范式优化、索引优化和查询优化三个方面对数据库的优化设计方法进行分析探讨。在逻辑设计阶段, 要按照范式优化的具体要求来设计数据库逻辑结构, 比较其优劣从而选择更好的方案;在数据库物理设计阶段, 在有关属性或属性的组合上建立索引时要根据索引优化中的具体要求来进行, 使数据库物理结构得以优化;在数据库查询阶段, 优化数据查询语句, 以提高SQL语句的执行效率。

关键词：数据库,范式优化,索引优化,查询优化

参考文献

[1]微软公司著.SQL Server 2005数据库开发与实现.高等教育出版社, 2007年9月.

[2]陈志泊.数据库原理及应用教程.人民邮电出版社, 2008年3月.

[3]吴碌莉.数据库优化设计方法初探[J].广西科学院学报, 2005年2月.

应用数据库营销策略优化客户获取 第2篇

为什么这么多的营销策划人员都热衷于客户获取营销呢?下面的这些原因可以用来解释这一点：

客户获取是增加客户市场份额最直接有效的方式之一。市场份额是非常重要的市场营销业绩考核指标，许多企业都将每年营销部门的重点设定在市场份额的保持和增加上，在电信业、消费电子、保险等等许多的行业都是如此。企业为此往往也定义了许多必须达到的业绩考核指标，这些指标往往是以增加客户市场份额为导向的，在这样的导向下，客户获取营销就成了营销策划人员最直接的考核指标。

客户获取比客户维系更容易测量营销的结果。客户获取营销只需要在营销活动结束后计算一下获取了多少客户，卖掉了多少产品就可以得到结果了。对于客户维系营销，计算营销活动的收益就不那么容易了，不仅需要计算维系营销活动的直接收益，还要跟踪客户的持续消费行为，测算营销带来的未来收益，这对于很多营销策划人员来说，并不一件容易完成的任务。也有不少营销策划人员认为，现有的客户本来就在一直购买，通过取悦现有客户进行维系营销的方式只是在浪费营销基金和资源。而来自客户市场的压力是实实在在，获取更多的新用户，促销新产品加快新产品的客户市场渗透期是最直接、最容易测量的营销选择。

客户获取营销比客户维系更容易实施。在对于客户维系难以把握的情况下，客户获取营销就成了最容易实施的活动。最近研究了几家跨国公司在国内市场的营销活动，绝大多数都是新用户发展和新产品推广活动，增加客户市场份额和新产品的市场渗透率是最多见的营销活动目标。增加客户获取有很多可用的方法，利用各种传统的大众营销方法和渠道来引吸客户，如果一种营销方式不太理想，可以再尝试换另一种方式，直到客户获取营销的效果体现出来。而客户维系营销就要难实施的多，首要从现有客户中识别维系营销的目标客户就是一个不小的挑战，不仅仅需要记录和识别现有客户的消费历史，还要测算这些客户的生命周期价值;其次，如果想要维系这些客户，还需要识别目标客户群的个体偏好，来策划相应的产品服务策略和客户沟通策略;更次，还需要建立测试和控制组来跟踪维系营销的效果。而真正掌握这些客户维系营销技术的营销策划人员并不太多。

当然，还一个很重要的原因是营销客户数据库。客户维系营销一定需要企业能够建立和维护一个营销客户数据库后才能更好的实施，而客户获取营销则并不一定需要企业有这样的数据库，有很多不依靠营销客户数据库的大众营销方式可以采用，企业也可以通过合作在市场上寻找到相应的潜在客户名单。另一个重要的原因是，营销策划人员往往对数据库营销应用缺乏能力和信心，在这种情况下，侧重于客户获取营销是一个安全的选择，很多传统的大众营销策略和媒介沟通方式可以选择，营销策划人员在缺乏数据库营销策略指导时并没有动力来碰相对复杂的客户维系营销，

正是因为上述的这些原因，市场营销主管将更多的精力放到了客户获取营销上。这一点看起来并不奇怪，但是在竞争越来越激烈的市场环境中，尤其是在寻求高价值客户异常竞争激烈的消费产品市场，采用传统大众营销方式常常已经不能达到预期的营销目标，对于高价值客户的营销和产品渗透是困扰每个营销策划人员的难题。

客户获取营销应当吸引哪些客户?他们能够为企业带来长期价值吗?如何能够比竞争对手更高效的策划和实施客户获取营销，以达到更高的客户获取营销投资回报率呢?有没有更好的改进客户获取营销呢方法呢?

本文从数据库营销的一些基本应用来浅析可以改进的方法。

一、避免获取错误的客户

很多营销策划人员仅仅关注营销活动在促销期间内获取了多少新用户，卖出了多少新产品，而很少关注这些客户中有多少是真正的目标客户，有多少是错误的客户。

有时，企业设计的一些优惠促销活动，本意是想吸引目标客户群，但经常没有到达真正的目标客户之前，就被那些对价格和优惠敏感的人一抢而空。经常能够看到一些商户在发各式各样的会员卡，这样的会员卡往往没有什么门槛，往往在初期有优惠的时候，会吸引大量的客户加入，而当优惠期过后，能够持续消费的客户门可罗雀，商家不得已，只得不断的通过各种各样的活动来吸引新客户，接下来还是客户的大量流失。究其原因，在以价格为促销活动主要诉求的营销实践中，对价格敏感的客户会占有相当大的比例，而这类客户往往是交易型客户，他们是奔着产品促销的优惠来的，他们的重复购买率相对忠诚的客户会很低。除非你的企业能够一直持续不断的给这类客户以刺激，才能保持他们的连续购买行为，而这样只是会浪费大量的市场营销预算在非目标客户身上，他们并不能为企业带来长期的利润。

以信用卡营销为例，近年来国内银行信用卡的发卡大战愈潜愈烈，促销手段层出不穷，通过开卡有礼、豁免年费、送保险、现金回馈、消费积分、免息购物等各种各样的营销活动来吸引信用卡新用户。有的银行在发展用户时声称，只要成功办理信用卡后，在规定日期内刷卡进行第一次消费，都可以获得价值百元甚至数百元的奖励。甚至通过媒体宣传“花明天的钱圆今日的梦”的适度信贷导向。但信用卡的新用户获取成本较高，客户盈利周期也较长，往往需要数年才能盈利，过度优惠的促销会将大批非目标客户吸引进来，无形中增加客户管理和客户服务的成本。同时，如果没有设计好完善的后续维系营销策略，从长期来看，对于高价值客户的维系和发展也是一个非常严峻的问题。

例谈科学实验数据的优化策略 第3篇

【关键词】实验数据 优化 策略

科学探究要培养学生的实证意识。数据作为探究实验中常见的记录手段，对事物、现象进行定性、定量分析时，它能使我们的条理更清楚，结果更精确，有着其他方法不能替代的作用。作为一线的科学教师，应重视对学生数据意识的培养，关注学生实验数据中出现的问题，并能合理地引导、利用，使简单枯燥的数字转化为优美动听的音符，谱写一首和谐的乐章。

一、排摸“特殊数据”

课前，教师一定要认真研读教材、 了解学生、熟悉实验器材， 做好下水实验。预设学生在实验中可能会出现哪些“特殊数据”， 并对造成这些“特殊数据”的原因进行初步分析，并据此规划和设计教学过程。如2014年度省小学科学理事会活动中，笔者执教了五年级下《摆的研究》一课。为了准备实验材料，笔者进行了多次“下水实验”。第一轮是用“添加钩码”的方法探究“摆锤的重量与摆的快慢是否有关”。试了几次，并将15秒内摆动的次数统计如表一。

观察这些数据，笔者发现数据与科学理论完全不符，分析其原因是挂钩码存在着问题：一个接在另一个下面，挂成一长条，不是挂成一横排，挂法不同导致了实际摆长发生了变化，当然摆动次数就变化了。于是笔者再次实验，把钩码挂成一排，得到的数据如表二。

第二轮的实验结果较前次在准确度上有很大提升。但不难发现，3倍重量的数据仍有误差。在多次实验后笔者发现，钩码挂在一起时，摆锤的体积变大，外形更加不规则，摆动时有些晃动，从而影响了摆的重力加速度。为了既不改变摆的长度，又不改变摆锤的大小，笔者改进了实验材料，把钩码换成了两个大小一样但轻重不一样的实心球。第三轮实验，结果令人满意。从整个下水实验可以得出，要减少“特殊数据”的产生，教师要选择合适的实验仪器。

所谓工欲善其事，必先利其器。教师在“下水实验”中排摸了“特殊数据”，找到了影响因素，并有效地进行了改进：从改变挂钩码的方式到改进实验材料。合适的实验材料为学生开展真正的科学探究提供了保障。

二、关注“缺失数据”

实验数据是科学探究过程的见证，更是得出科学结论的依据。没有了这些数据，或者说缺少了部分数据，会直接影响实验的效果。然而，在科学探究活动中，学生得到的数据并不是“十全十美”的，存在着缺失现象，或遗漏，或不全，对此教师应适时引导，关注这些数据，增强学生对数据的敏感性，使学生从被动记录到主动分析数据，能自觉运用数据来解决问题，提高探究效率。

如教科版三下《磁铁有磁性》一课，笔者让学生通过实验完成磁铁能吸引哪些物体的实验记录：能被磁铁吸引的物体请打“ √”，不能被磁铁吸引的物体请打“ ×”。笔者巡视到其中一个小组时，发现了如下的实验记录：

笔者发现这个组有两项没有填，觉得很疑惑：“你们还没有完成吗？他们组都好了。”组长迫不及待地回答说：“老师，不是的。我们猜测纸片和泡沫是不会被磁铁吸引的，但实验了几次后发现有些碎纸片和小块的泡沫也会被吸引。所以我们不知道怎么填，就空在这里了。”此时，笔者引发学生思考：“为什么磁铁只吸引这些碎纸片、小泡沫呢？”此时，教师邀请他们上讲台再次进行实验验证，通过实验他们发现：“小纸片、泡沫原来不是真正被磁铁吸住，是由于天气干燥、磁铁发热等客观原因造成静电现象吸附在磁铁上面，是一种假象。”学生恍然大悟，教师顺势让学生迁移到以前学过的静电现象。

对于此表格数据缺失的原因，主要还是学生对生活的观察和体验较少，教师要引导学生通过其他渠道去观察和体验，因为只有通过比较直观的视觉体验印象才深刻。这就要求教师要能准确把握学生的原有认知，不武断地作出不合理的判断，以免抹杀学生学习的积极性，在充分了解情况的前提下，启迪学生解决问题，发现真知。

三、扼制“虚假数据”

蹲下身来，深入学生，参与学生的探究过程，了解真实的数据，对于培养学生的实证意识至关重要。这个过程，不仅能拉近师生之间的关系，让教师及时发现学生中出现的问题，还能有效避免学生在实验时敷衍了事、弄虚作假。笔者曾经在执教五年级上《蚯蚓的选择》一课时，就遇到过学生“创造”虚假数据的情况。笔者让学生同时探究土壤和光亮的条件。其中有5个组进行了“蚯蚓喜欢潮湿还是干燥的土壤观察”的实验。观察实验后，学生反馈数据记录如下：

在参与各个小组的探究实验的过程中，笔者有意识地了解了各组的实验数据，并且根据数据的特征，选择了3个组（第1组、第2组和第8组）进行汇报。其中第8组的数据比较特殊，待在中间的蚯蚓比较多。可是当第8组的代表上台汇报时，笔者却发现他们把数据改了，改得和第2组的一模一样。以下就是第8组前后数据的比较（单位：条）：

笔者问他们为什么没有如实回答，一位学生说“其他组的结果都是两边的多，我们肯定是错的！”其他组员则红着脸不说话，典型的人云亦云，从众心理。笔者再问“在实验过程中，实验的真实情况是怎样的呢？”他们的头更低了！他们的记录是实验的真实反馈，可他们却没有如实面对。对此，笔者没有在课堂上继续追究，而是选择在课后与他们小组进行了再一次的实验探究。

盲目的从众心理会影响学生的判断力，会抑制学生个性的发展，束缚思维，扼杀创造力，使人变得缺乏主见。而科学的探究活动追求的就是真实，发展的是学生的个性，这种因盲目的从众心理而“复制”出来的“虚假数据”，必须加以扼制，抹去浮华，使学生的探究回归科学的本质。当然这种扼制还应该是有节制的、委婉的、机智的，不能适得其反。

四、巧用“另类数据”

科学探究过程中，由于实验方法、实验器材以及每个人的观察力、操作能力等不同，实验观测值和标准值之间，总是存在着一定的差异，会出现一些另类的数据，有可能是错误结论，也有可能是另含玄机。这就需要教师善于捕捉这些信息，善于引导学生分析这些数据之后的科学知识。

例如六年级上《做框架》一课，要求学生设计制作一个可以支撑重物的正方体框架。各小组完成了设计图之后便开始实验承重能力。几分钟后，小组探究结束，教师将各组数据一一展现在课件中。

接着，教师让学生仔细观察这些数据，找出其中的规律。在静静地思考1分钟之后，有学生发言：“斜杠越多，承载能力越大。”教师追问：“你是根据哪些数据找到这个规律的？”这位学生继续以第3组、第5组和第8组的数据进行比较。此时，有学生进行了反驳：“我不同意你的说法，如第2组和第4组比较之后，斜杠少的反而承载能力更好。”此时，教师巧妙利用这个生成点，让第2组的学生现身说法，上台展示作品，当场实验（斜杆架在正方体框架的对角线上）。实验后的真实情况让学生心服口服。接着教师再次追问：“第2组的作品为什么承重力就大了呢？你又有什么新的发现？”学生纷纷举手，概括出了“三角形框架越多，承载能力越大”的结论。教师从“另类数据”激发了学生积极的思考，引发了冲突，继而合理地利用了这个冲突，使学生的理解更加深刻。

特级教师章鼎儿曾指出：小学科学教学过程中，学生犯“错”是难免的事，从某种意义上说，越出“错”反而越真实、越科学、越全面、越深刻。学生在探究过程中出现的各种另类数据，同样是真实的、科学的，是现实状态的反映。当科学课堂中出现另类数据时，教师要勇于直面意外，引领学生去思考、去发现：重视事实根据，合理怀疑；倾听和考虑他人的不同观点或解释；多次实验，根据新的证据，怀疑、修改自己的意见。让学生在质疑、改进的过程中得到锻炼与提升。

五、拾撷“繁杂数据”

数据收集的过程亦是学生实验、实践的过程，也是学生最喜欢的环节。学生在科学探究活动中，收集的数据有时会特别多，看上去会有些凌乱，它们就像一颗颗散落的珍珠，只有通过整理、分析——去粗取精，才能集成一串，成为项链，才能发挥数据应有的作用。同时，当学生面对大量数据时，往往会显得手足无措。教师此时就应该从学生角度出发，按照一定的方法厘清关系，寻找真知。例如在2015年浙江省小学科学特级教师网络工作室的研讨活动上，有教师执教了三年级下《磁铁的两极》一课，教学过程中该教师采用了磁感应传感器，让每个小组的学生进行充分的实验，得出了大量的实验数据，如下表。

（续表）

以上数据对于学生来说，烦琐难懂。就连台下听课的教师也为这些学生担心。课堂沉寂了一段时间之后，该执教教师进行了恰当的引导：“我们可以竖着观察一列数据，也可以横着比较一行数据。大家再观察比较一下。”方向明确了，方法了解了，学生的思路就打开了。接下来的小组讨论非常热烈，汇报环节更是精彩纷呈。学生不仅明白了不同的磁铁磁力大小不一样，而且还发现了同一块磁铁中，两端的磁力最大，中间的磁力最小。

面对数量众多的数据时，学生往往会无从下手，这就需要教师点拨引导，把有关联的数据放在一起比较，使这些“零珠碎玉”发挥价值，让学生在思考、讨论中找出数据中隐含的规律、联系，串成更有价值的珍珠项链。

在科学课堂教学中，“用数据说话，用数据验证”这一观点贯穿于整个科学课堂教学中。通过培养学生的数据意识，使学生通过探究寻求正确的数据来证明自己的观点，并自觉运用数据解释相关的问题和现象。用数据说话，有助于学生寻找规律；用数据验证，有助于学生探究，从而得出正确、科学的结论，也能使探究活动变得更真实、更准确、更有效。

参考文献：

[1] 张红霞.科学究竟是什么[M].教育科学出版社，2003.

[2] 吴利坚.不该被漠视的数据[J].科学课.2007（4）.

数据库查询优化策略分析 第4篇

1 基于SQL查询语句的查询优化办法

在SQL中要提高查询效率,除了提高网速、把数据、日志、索引放到不同的I/O设备上,以增加读取速度等措施以外,对查询语句进行优化也是常用的提高查询效率的办法。从用户的角度实现查询优化主要是通过对SQL语句进行调整,减少计算量,提高查询。以下就对SQLServer数据库查询方法作一下探讨。

1.1 合理建立和使用索引

索引是数据库中重要的数据结构,它的根本目的就是为了提高查询效率。现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构。索引的使用要恰到好处,其使用原则如下:

1)在频繁进行排序或分组(即进行group by或order by操作)的列上建立索引。

2)在经常进行连接的列上建立索引,而不经常连接的字段则由优化器自动生成索引。

3)不要对只有有限几个值的字段建立单一索引。例如若对“性别”字段建立了索引不但不会提高查询效率,反而会严重降低更新速度。

4)如果等待排序的列有多个,就在这些列上建立复合索引(compound index)。

1.2 避免相关子查询

查询嵌套层数每增加一层,查询的效率成几何级的降低。要想提高嵌套语句的执行效率,应减少嵌套语句的嵌套层次。所以在实际应用中,使用连接查询代替子查询可以提高效率。

如:查询选修了05号课程的学生基本信息,用子查询得方法如下所示:

改成连接查询如下:

1.3 数据类型的优化

数据类型的优化中最主要的问题就是在WHERE子句中对具有不同类型的属性的比较。例如float与int,char与varchar,binary与varbinarv,money与int是不兼容的,因此要求

WHERE子句中表达式的数据类型是兼容的。例如,有如下SQL语句:

由于WHERE子句中,字段price是货币(money)型字段,而20是整型数,优化器无法对其进行优化,只有耗费一定的时间将整型数20转化成money型字段后,才能进行优化,才能与字段price进行比较因此,在编程时可将整型数20先转化成money型字段,而不要等到运行时由系统来转化,即语句改为:

1.4 对多个表查询时,将返回结果集记录数较少的表放在后面

对多个表格进行查询操作时,FROM子句中表格的次序也影响查询的响应速度。设学生档案管理系统中有一个表students,还有一个与students结构类似的表students1,students中2010年9月5号入学的学生有1000个,students1中2010年9月5号入学的学生有200个,若要查询students和students1两个表中2010年9月5号入学的学生,则SQL语句将返回包含所有1200个记录的表,相应的SQL查询语句如下:

在具体的执行过程中,先对表格students进行选择运算,得到1000个记录的临时表,再对students1进行选择运算,然后将得到的符合条件的200个记录插入到1000个记录的临时表中,需200次插入运算。若将FROM语句后面的表次序对换,即为“FROM Students1,Studentds”,则先得到一个200行的临时表后,需要做1000次的插入运算,其工作量远大于第一种情况,故可将返回较少记录的表格排在后面,较多记录的表格排在前面,以便减少插入运算。

1.5 使用临时表优化查询

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

如:查询每个部门中月工资最低的“职工编号”

Select职工编号from职工as al where月工资=(select min(月工资)from职工as a2

where a1.部门号=a2.部门号)

以上查询对于外层职工关系a1中每一个元组,都要对内层整个职工关系a2进行检索,

查询效率不高。但是可以通过构建临时关系的方法提高查询效率:

Select min(月工资)as最低工资,部门号into temp from职工group by部门号

Select职工编号from职工,temp where月工资=最低工资and职工.部门号=temp.部门号

2 通过优化器实现查询优化

实际的DBMS对查询优化的具体实现方法不尽相同,一般地可以归纳为四个步骤:

1)将查询需求转换成某种内部表示,通常是语法树。

2)根据一定的等价变换规则把语法树转换成标准形式。

3)选择低层的操作算法。对于语法树中的每一个操作需要根据存取路径、数据的存储分布、存储数据得聚簇信息来选择具体的执行算法。

4)生成查询计划。查询计划也称执行方案,是由一系列内部操作组成的。这些内部操作按一定的次序构成查询的一个执行方案。通常这样得执行方案有多个,需要计算每个执行方案的执行代价,从中选择代价最小的一个。

通常对优化器的查询优化都是基于第2个阶段的,由原查询开始,优化器对查询形式进行转换,直至它认为所得到的形式一句某些启发式规则已经是最优的为止。

3 结束语

随着数据库技术的发展,数据库系统占据着越来越重要的地位。现代数据库规模越来越大,数据量呈指数级上升,数据库查询性能的优化越来越引起人们的重视。从大多数系统的应用实例来看,查询操作在各种数据库操作中所占据的比重最大,而查询操作所基于的SELECT语句在SQL语句中又是代价最大的语句。如果数据的量积累到一定的程度,全表扫描一次往往需要数十分钟,甚至数小时。如果采用比全表扫描更好的查询策略,往往可以使查询时间降为几分钟,由此可见在系统的开发过程中,充分利用SQL查询语句的基本优化方法,可以明显的提高SQL查询语句的执行效率。

参考文献

[1]萨师煊.数据库系统概论[M].北京:高等教育出版社,2003.

[2]黄维通.SQLServer简明教程[M].北京:清华大学出版社,2002.

[3]尹萍.SQLServer数据库性能优化[J].计算机应用与软件,2005,22(03).

数据库优化策略分析 第5篇

【关键词】 数据库 逻辑设计 物理设计 性能优化

一、引言

SQL Server数据库的性能受到多种因素的制约，比如数据库的结构、数据库的载体操作系统、硬件水平等等。在上述诸多因素中，有些情况必须要改变客观的情况才能够优化数据库性能，这些因素基本包括数据库本身因素之外的其他因素。而有些因素仅与数据库系统本身有关。本文对数据库结构对数据库性能的影响进行了研究，并针对数据库设计的改进来对数据库的性能进行优化。数据库的设计总是和实际应用紧密相结合的是面向客户的基本需求的，因而数据库的设计应该从客户的需求来出发进行设计。数据库的设计首先是为了满足客户的需求并且具备较好的性能，因而可以看到优化数据库的性能是数据库设计最为基本的要求之一，由于数据库的优化与数据库的设计二者紧密相关，而数据库的设计一般包括数据库的逻辑设计、数据库的物理设计以及事物日志设计等。

二、结构设计要点

要通过对数据库的设计来实现对数据库的优化，首要的是熟悉数据库的基本结构，这是通过结构设计进行数据库优化的基础。数据库一般包括一个主数据文件以及一个多人事务日志文件，此外在有些数据库中还有辅助数据文件等。一般讲主数据文件看做是整个数据库的起点。该主数据文件会指向数据库中其他的文件。主数据文件中一般会包含数据库文件的启动相关信息，主要用于存储数据，主数据文件是每个数据库所必须的。事务日志文件一般包括恢复整个数据库所需要的日志文件信息。作为数据库来说日志文件也是必须具备的，数据库可以通过数据库的日志文件来恢复数据库。辅助数据文件是相对于主数据文件来讲的，主数据文件主要是指除外主数据文件以外的全部的数据文件。因而如果主数据文件包含所有的数据文件时就不需要辅助数据文件，而实际可能的情况是由于数据库比较大而会存在多个的辅助数据文件。系统表中的model数据库会在数据库创建的过程中被转移到数据库当中。在数据库中最小的存储单位为页，其中每页为8kb的磁盘空间。在数据库中行不能够跨页，扩展是数据库的又一基本单元，可以将空间分配相应的表或者是索引。事物的日志文件含有可以恢复数据库的重要的信息，这在数据库发生故障或者是崩溃的时候尤为重要。了解数据库结构设计要点对于在数据库设计的过程中对数据库进行优化以及规范具有十分重要的意义。可以通过对数据库文件以及事物日志映射的方式来进行管理，就能够实现优化数据库的目标并能够具有较好的系统容错性。

三、数据库逻辑设计

数据库的逻辑设计主要是根据实际的业务需求和所需的数据建立数据模型。主要是对表与表之间的关系进行规范和设计，这是数据库优化的重要核心问题。从数据库结构设计对系统性能优化的整个影响机制来看，数据库的逻辑设计是对整个数据库进行性能优化的基础环节也是最为重要的环节。而数据库逻辑设计优化的过程也就是使用规范、简洁的关系来代替原来关系的一个过程。如果一个关系所有的字段都已经不再可分，那么这种关系就是规范化的逻辑关系。该关系满足数据库逻辑设计的第一范式，在此基础上进一步将属性和关键字之间进行消除可以得到第二范式，进一步消除属性与关键字之间的传递函数关系就可进一步得到第三范式，这种关系规范化的过程就是对关系进行分解的过程，因而在数据库的逻辑设计过程中必须要满足第三范式。实际上逻辑设计就是将数据分布到各个表的技术，使用规范化的设计技术能够有效的消除数据的冗余，将数据之间的层次关系理清楚，有效的保证数据库的完整，使得数据库的稳定性较好能够较为智能的解决删除时的异常。数据插入异常，也就是相关数据信息未插入到数据库当中以及更新问题等。

数据库的规范化在一定程度上降低了冗余的数据，数据库冗余数据的减少使得其在数据库中数据量有效的减少了，进而能够减少存储数据的页，这对系统查询性能具有一定程度的提升，有效的避免了数据库中多个位置有一个数据的情况。能够显著提升应用程序的效率并且能够减少数据库使用过程中所出现的错误。

但是规范化的设计有时候也会对系统的性能产生一定程度的影响，规范化实际上是将二维表分解为最小组分的表，所以对于一些查询运算可能就需要完成较为复杂的联结运算，复杂的联结运算会导致计算机运行的时间、空间以及效率的损失，且使得客户端的编程难度也极大的增加会导致较为明显的性能的下降。所以必须要对其规范化进行平衡，使用反规范化来相应的提高系统查询的速度。

四、物理设计

数据库物理设计的过程是将逻辑设计映射到物理设备上的一个过程，使用相应的软件功能可以较为方面的实现对数据库进行物理访问，数据库使用I/O接口函数来实现对数据的读写，其中磁盘设备往往会成为影响数据库性能的主要方面，在这种情况下用户可以将数据最大限度的分解到多个磁盘上，在这种情况下可以采取并行访问的方案来提高文件访问的速度，可以将每个物理磁盘创建为一个文件并设置相应的文件分组，在这过程中可以使用RAID技术来实现对数据库性能的优化。该设备允许对多个磁盘进行条带化，可以便于使用更多的磁盘进行同时进行数据的读写，然后进行查询，可以有效的提高数据查询的效率。

五、结语

通过对数据设计对数据库性能的影响分析可以看到数据的逻辑设计过程中使用规范化的设计能够在一定程度上减少数据冗余进而提高数据库系统的性能，但是逻辑规范化的设计也会存在着一定的问题可以通过反规范化设计进行均衡。物理设计过程中对数据库性能影响较大的因素为物理磁盘设备，可以使用RAID技术来对物理结构进行优化设计从而允许对多个磁盘的读写提高数据库查询的效率。

参 考 文 献

[1] 任巍. 铁路巡检作业信息实时管理系统的数据库设计[J]. 信息与电脑（理论版）. 2015（02）

[2] 谭峤. SQL Server数据库性能优化研究[J]. 硅谷. 2014（08）

数据库查询优化策略探究 第6篇

关键词：DBMS,查询优化,优化策略

数据库技术作为信息管理系统的核心技术, 在信息处理领域越来越受到重视。在数据库系统的各种操作中, 其中数据库的查询操作是其核心操作, 是最重要的, 也是最复杂的。SQL (Structure Query Language) 作为国际标准的数据库查询语言, 其核心功能就是查询技术。目前主流的DBMS均支持SQL语言或者有与SQL的接口软件。所以, SQL语句的执行性能的高低直接影响着数据库应用系统的运行效率。因此, 优化SQL查询语句, 可以节省数据查询操作的时间和空间, 提高效率。

一、实现DBMS查询优化的常用策略

数据库查询优化的总目标是:选择有效的策略, 求的给定关系表达式的值。关系运算理论是SQL语言的理论基础。关系代数语言是以集合操作为基础的语言。查询优化的步骤为: (1) 首先, 给出SQL语句后, 查询优化器对查询语句先需要做代数优化和存取路径的优化。 (2) 其次, 由预编译模块对语句进行处理并生成查询规划。 (3) 最后, 在合适的时间提交给系统处理执行。也就是由DBMS确定合理的有效的查询策略, 这称为DBMS的查询优化。查询优化一般会常用以下几种优化策略:

(一) 应尽可能先做选择运算, 以得到较小的中间结果。

这是查询优化策略中最重要也是最基本的一条。选择操作就是根据选择条件对关系做水平分割, 即选取符合条件的元组 (记录) 。先做选择操作, 可以大大减少中间结果, 减少运算量, 后面其他运算的运算时间也大大减少。

(二) 在执行连接操作的时候, 首先对关系进行预处理。

预处理的一般方法就是对关系建立合适的索引或者排序。现在的DBMS一般都是采用索引的方法。索引是数据库操作中重要的数据结构。其使用原则如下: (1) 在经常进行连接但没有指定为外键的列上建立索引, 这样的列一般是关系中的关键字, 而不经常连接的字段则由优化器自动生成索引。 (2) 在频繁进行分组group by操作或排序order by操作的列上建立索引。 (3) 在条件表达式中经常用到的重复值较少的列上建立索引, 在重复值较多的列上不要建立索引。如果在重复值较多的列上建立索引, 不但不会提高查询效率, 反而会严重降低更新的效率。 (4) 如果是多关键字排序, 可以建立复合索引。

(三) 对同一个关系进行的选择运算和投影运算应该尽量的同时进行。

如果选择和投影运算都是针对同一个关系的, 可以对关系连续做一串操作, 即同时计算一连串的选择和投影操作, 以免多次扫描文件, 从而节省时间。

(四) 对关系的一个子集排序并且创建临时表, 能加速查询。

创建临时表有助于避免多重排序操作, 还能简化优化器的工作。临时表是主表的子集, 其行和列要比主表中的行和列少, 而且元组物理顺序就是所要求的顺序, 减少了磁盘输入输出操作, 所以查询工作量可以得到大幅减少。在SQL中, 临时表的建立一般是通过建立视图的方法来实现。需要注意的是:临时表创建后不会反映主表的修改, 在主表中数据频繁修改的情况下, 应该经常更新视图, 以防丢失数据和数据错误。

(五) 应尽量避免对大型表的顺序存取。

在嵌套查询中, 大型表的顺序存取对查询效率可能产生致命的影响。避免这种情况的主要方法就是对连接的列建立索引, 按照索引路径来完成连接运算, 从而可以大大降低连接运算的执行代价。

二、实现SQL语句查询优化的常用方法

SQL语言作为一种非过程化的查询语言, 用户仅表达查询的要求, 而不必描述查询的过程。要想设计高性能的SQL语句, 首先要做到三点: (1) 熟悉所用的DBMS优化器的优化策; (2) 深入理解数据库中的数据; (3) 透彻的分析用户的需求。然后在此基础之上, 才能尝试编写效率最高的SQL语句, 优化程序设计。完整的SQL语句有5个子句构成。其格式如下:

SELECT目标表的列名或列表达式序列;

FROM基本表或视图序列;

WHERE行条件表达式;

GROUP BY列名HAVING分组条件表达式;

ORDER BY列名ASC/DESC;

在SQL语句中, 通过优化各个子句的方法, 同样可以提高查询效率, 下面是在数据库中常用的一些提高SQL语句性能的方法。

(一) SELECT子句的优化方法。

当需要在SELECT子句中列出关系中所有的列时, 使用*是一个很方便的方法, 但是, 这种方法的执行效率很低, 因为在解析这类语句时, 优化器首先要查询数据字典, 将*转换成所有的列名, 这个过程将花费较多的时间, 所以要尽量避免*的使用。

(二) WHERE子句的优化方法。

1. 合理设置WHERE子句中的条件顺序。

因为大部分的SQL语句解析器解析语句的循序都是自上而下的, 所以条件的循序应该是:表和表之间的连接条件必须写在其他条件之前, 而那些可以过滤掉最大数量元组的条件则必须写在WHERE子句的末尾。如果按照条件限制的严格程度设计WHERE子句, 则需要将条件限制最严格的部分放在末尾, 而将条件限制最不严格的部分放在顶部。

2. WHERE子句中对列的任何操作都将导致对表扫描。

如, SELECT*FROM student WHERE substr (sno, 1, 4) =“2006”应改为SELECT*FROM student WHERE sno LIKE“2006%”。应当避免对WHERE子句中的条件参数使用其他数学操作符, 如果WHERE子句中存在一个代数表达式, 那么优化器就不能使用分布统计信息。

3. 避免使用困难的正规表达式。

所谓正规表达式, 是指在SELECT查询语句中LIKE关键字支持的_和%通配符匹的使用。但实际的执行中, 这种正规表达式的匹配非常耗时, 如上例从Student表中查询2006级所有学生信息, 即使在Sno列上建立了索引, 优化器还是会采用顺序扫描方式处理该SELECT语句。可以把SELECT语句改为如下形式:SE-LECT*FROM Student WHERE Sno>‘2006000000’AND Sno<‘2007000000’, 去掉通配符的使用, 改用关系表达式给出条件, 则优化器就会利用索引来执行查询, 显然会大大提高查询速度。

4. 在WHERE子句中应使用子查询时尽量使用EXISTS (NOT EXISTS) 而不是IN (NOT IN) 。

在子句中可以使用两种格式的子查询:第一种格式是使用操作符:Where xi IN (WHERE……….) ;第二种格式是使用操作符:Where xi EX-ISTS (WHERE……….) 。使用EXISTS (NOT EXISTS) , DBMS系统的执行循序是:首先检查主查询, 然后运行子查询直到找到第一个匹配项。这样就节省了时间。如果使用IN (NOT IN) 子查询, 则系统先将主查询挂起, 首先执行子查询, 并将获得的结果列表存放在一个加了索引的临时表中, 待子查询执行完毕, 存放在临时表中以后再执行主查询。因此。使用EXISTS (NOT EXISTS) 要比使用IN (NOT IN) 查询速度快。因此, 在WHERE子句中使用子查询时, 应尽量使用EXISTS (NOT EXISTS) 而不是IN (NOT IN) 。在写SQL语句的时候, 同样也应该尽量用UNION而不是OR操作符, 这样也会起到加快查询速度的作用。

5. 用WHERE子句代替HAVING子句。

HAVING子句很有用, 但是用起来要付出很大的代价。因为HAVING子句的执行将导致SQL语句优化器的额外工作, 从而花费额外的时间, 所以应当尽量避免使用HAVING子句。HAVING子句和WHERE子句类似, 都能根据条件对关系进行筛选.但HAV-ING子句必须配合GROUP BY来进行筛选, 否则没有任何意义, 但WHERE子句可以不带GROUP BY。WHERE子句HAVING子句的执行顺序也略有不同:WHERE子句先根据条件对记录进行过滤而形成结果集, 然后再进行分组 (如果带有GROUP BY) 。而HAVING子句则首先要通过GROUP BY检索出所有记录, 然后才根据条件对结果进行过滤, 其处理过程中还用到排序、总计等操作。所以, 如果能用WHERE子句来代替HAVING子句, 则能较好的减少系统的开销, 提高SQL语句的执行效率。

(三) ORDER BY子句的优化方法。

在ORDER BY子句中, 不要有非索引项或者计算表达式。ORDER BY语句决定了DBMS如何将返回的查询结果排序。在ORDER BY语句中, 如有非索引项或计算表达式, 则将降低查询速度。

(四) 其他优化方法。

利用SQL语句查询, 还有一些优化方法, 例如:合理使用索引, 尽量避免使用排序;简化或避免对大型表进行重复的排序;避免对查询的列使用数学运算;使用临时表加速查询等等。

三、结语

总之, SQL优化的实质就是在结果正确的前提下, 用优化器可以识别的语句, 尽量减少类型转换和计算, 充分利用索引, 减少表扫描的I/O次数, 尽量避免表搜索的发生。查询优化是一个复杂的问题。随着数据库技术的广泛应用, 理解关系数据库查询优化的实现方法, 书写合理的查询计划, 借助于关系数据库查询优化的新技术, 可以使数据库应用系统的性能得到更大程度的提升, 人们的工作效率得到进一步提高。

参考文献

[1].萨师煊.数据库系统概论[M].北京:高等教育出版社, 2004

[2].[美]Microsoft公司著.SQL Server2000资源大全[M].北京:机械工业出版社, 2002, 2

[3].陈建荣, 叶天荣.分布式数据库设计导论[M].北京:清华大学出版社, 1993:86～89

数据库优化策略分析 第7篇

如果脱离Web层应用组件测试仍然存在性能问题, 需要进一步跟踪数据库应用, 判断开销主要来源于SQL还是PL/SQL, 然后再进一步做性能分析。数据库的结构设计、空间规划及参数调整、甚至是项目结构调整通常根据系统的需求而定, 主要由系统分析员和数据库管理员来共同完成。实际上, 不同的SQL实现方式之间的效率差异可能会非常大, 尤其是在大数据量复杂数据库环境下表现尤为明显, 对于千万级别数据量的数据库, 执行一条关联几个大表的SELECT语句可能会消耗几十分钟, SQL语句的低效直接导致系统性能低下。高效的SQL语句来自于满足SQL语句的优化原则, 使用充分的连接条件, 优化的WHERE子句, 以及适当的索引设计。可以利用一些工具, 例如执行计划及跟踪文件等, 帮助调试SQL语句以获得最优效果。下面先了解在构造SQL语句时应当遵循的一般优化原则。

2 优化策略

2.1 性能设计的优化

2.1.1 在SQL语句中, 查询所有列时尽量不使用“*”符号

在查询某个表的所有列时, 我们经常使用SELECT*FROM table这种方式, 这种查询方式, 把“*”符号转换为表的所有列, 再将查询结果返回给用户。这是会消耗系统时间的, 所以建议在写SQL语句时, 把实际列名写出, 即使包含全部列。如在专业表中有专业编号与专业名称两列, 那么也就是使用‘SELECT专业编号, 专业名称FROM专业表’而不用SELECT*FROM专业表。

2.1.2 编写SQL时使用相同的编码风格

SQL语句被发送到服务器进程后, 要经过语句解析、语句执行以及返回结果几个步骤。在语句解析阶段, 首先判断在共享的SGA区中是否能找到完全相同的SQL语句, 如果找到就省去解析步骤, 直接使用现有的执行计划, 否则再去执行解析步骤。所谓完全相同是指SQL中的字段位置、大小写、空格个数等完全等价, SQL中所指的对象必须完全相同。

2.1.3 使用TRUNCATE语句替代DELETE

如果要删除表的全部记录, 可以使用不带WHERE子句的DELETE语句实现。但TRUNCATETABLE速度更快, 并占用更少的系统资源和事务日志资源。DELETE属于DML语句, 每次删除一行, 同时在事务日志中记录删除动作, 在UNDOSEGMENT中保存删除的信息, 以备操作撤销, 而TRUNCATE语句只在事务日志中记录所释放的数据页, 不保留任何所删除的数据, 所以速度比DELETE更快。执行DELETE语句后, 表所占用的空间是不释放的, 而TRUNCATE语句释放表所占用的全部空间。所以TRUNCATE是执行删除全部表记录时效率比较高的操作。

2.2 使用SQL语句提高数据库性能进行优化

2.2.1 有效使用LEFT JOIN

LEFT JOIN左连接查询是SQL中一个常用的功能, 它可以用于检索第一个表中的所有行与第二个表中所有匹配的行, 以及第二个表中与第一个表不匹配的所有行。如下表所示:

表A与表B左连接查询结果表C

由此可以看出LEFT JOIN消耗的资源非常多, 因为它们包含与NULL (不存在) 数据匹配的数据。LEFT JOIN比INNER JOIN消耗更多的资源, 过度的使用该语句, 必然会使系统增加运行负荷。为了提高数据库的运行速度的最简单方法改善数据库的设计方法。在数据库中全部使用此概念可以为您节省大量的处理时间。对于用户而言, 即使几秒钟的时间也非常重要, 因为当有许多用户正在访问同一个联机数据库应用程序时, 这几秒钟实际上的意义会非常重大。

2.2.2 排序语句 (Order by)

Order By语句的功能是对SQL数据库返回的查询结果进行排序。Order by语句对要排序可以将函数加入列中 (包括联接或者附加等) 。但是在Order by语句的非索引项或者有计算表达式将会降低查询速度。解决这个问题的办法:重写order by语句以使用索引;或为所使用的列, 创建另外一个索引, 同时应绝对避免在order by子句中使用表达式。

2.2.3 逻辑语句 (NOT)

SQL语句中常用的逻辑表达式, 比如大于 (>) 、小于 (<) 、等于 (=) 、大于等于 (>=) 、不等于 (!=) 等, 还可以使用and (与) 、or (或) 、not (非) 。not是用来对任何逻辑运算取反。

2.2.4 EXISTS和IN

在编写SQL语句时, 经常需要在子查询中获取一个值列表, 在主查询中使用IN去比较列数据是否在值列表中, 这种方式实现SQL比较简单和结构清晰。EXIST则是首先执行主查询, 再运行子查询直到找到第一个匹配项。在大多数SQL调优的观点中, 建议在业务密集的SQL当中尽量不采用IN操作符, 而使用EXIST替代IN, 效率会提高。具体在选择IN或EXIST操作时, 要根据主表和子表的数据量大小来具体考虑。如果两个表数据量相差悬殊, EXIST适合外表小而内表大的情况, IN适合外表大而内表小的情况。

3 结束语

数据库是数据资料管理、存储与处理的重要技术, 数据库系统的性能是决定信息资源使用效率的根本, 如果在保证数据查询准确的同时提高数据查询的速度, 是影响数据库系统应用效率的重要因素, 只有完成性能优化才能保证数据库的高效利用, 达到更高的资源应用要求、产生更高的价值。

参考文献

[1]王珊, 陈红编著.数据库系统原理教程[M].北京:清华大学出版社, 1998.

[2]杜兆将, 郭鲜凤, 刘占文.SQL Server数据库管理与开发[M].北京:北京大学出版社.

[3]李伟红.SQL Server2000实用教程[M].中国水利水电出版社, 2003.

分布式数据库查询策略的优化方法 第8篇

从物理上来讲,分布式数据库的数据分布在计算机的各个不同站点上,这些数据是一个逻辑的整体,同由分布式数据库进行全局的管理。分布式数据库的作用主要是存储数据和方便、快捷的查询数据,因此查询策略的优化已经成为了分布式数据库的一个核心问题。该文主要论述了分布式数据库的查询策略以及一些有效的优化方法和提高策略。

2 分布式数据库及查询优化分析

分布式数据库系统从物理上来讲是分散的,而从逻辑上来讲是一个统一的系统,它是将分布在不同站点上的逻辑单位通过计算机网络连接起来。按照数据模型的类型,分布式数据库系统可以分为同构同质型DDBS、同构异质型DDBS以及异构型DDBS三种[1]。同构同质型DDBS中多种数据库类型采用了同样的型号,而且数据库内的数据模型属于一个类型;同构异质型DDBS数据库内的数据模型采用的也是同一型号,但是数据库类型却不相同;异构型DDBS中的数据库类型和数据模型均不一样。

按照分布式数据库的控制系统可以将分布式数据库系统分为集中式DDBS、分散性DDBS以及可变型DDBS。集中式DDBS在一个节点上保存全局的控制信息,所以容易实现整个分布式系统的数据一致性;但是这一种分布式系统存在一定的单点故障,一旦存放全局控制信息的节点出现问题,整个分布式系统将不能继续使用。分散性DDBS在每个节点上都保存了全局控制信息的一个副本,虽然这样可以保证整个分布式系统的稳定性,但是却难以保证所有节点上数据的一致性。可变型DDBS综合了上述两种分布式系统的优势,只有一部分节点保存全局控制信息,这些节点被称为主节点;没有保存全局控制信息的节点称为辅节点。

对分布式数据库系统而言,数据库中数据的分布性使其查询操作比一般的数据库更加复杂,而且目前还没有一种能够适用于所有分布式数据库系统的有效方案。从众多的数据查询方法中找到一种最优方案就成了衡量分布式数据库系统的重要依据。一般而言,衡量数据查询方法优劣的重要依据是查询代价和响应时间,即在数据查询期间,数据查询操作所耗费的处理器代价是否足够小,数据查询的响应时间是否足够短。除此之外,分布式数据库数据的分布性,使得在进行数据查询的优化时,还要考虑网络通信因素。在对分布式数据库的查询策略优化时,一般有两种优化目标[2]:降低查询代价或缩短数据查询的响应时间。查询代价由处理器的执行时间和输入/输出的处理时间两部分组成,在降低网络通信代价的同时可以减小查询代价,从而起到优化分布式数据库查询操作的作用。分布式数据库能够进行数据的并行查询,并行处理操作降低了查询时间。

在分布式数据库系统中,查询操作主要有远程查询、本地查询以及全局查询三种类型。本地查询只在本节点上查询数据库数据,远程查询可能在其他节点上查询数据,全局查询会在多个节点上查询数据,所以可以认为是局部查询和全局查询的结合。远程查询和全局查询会查询其他节点上的数据,所以会涉及到网络通信,研究查询优化算法时,这二者是经常需要研究的该节点。进行远程查询时,由于不同节点的通信代价不同,所以选择不同的分布式数据库节点可能会得到不同的查询效率,如何选择分布式节点以得到最小的查询代价,就是查询优化的一个重要问题。全局查询会涉及到多个节点,比远程查询更复杂;为使执行全局查询时得到较好的优化结果,通常要完成四种优化策略[3]:(1) 数据副本个数的确定。分布式数据库的数据一般是冗余存储的,即一份数据可能保存到多个分布式节点上。如果一个查询涉3及到的所有数据都只有一份副本,那么此查询过程就可以称为非冗余具体化,否则的话就称为冗余具体化。当查询数据有多个副本时,不同的数据片段会影响查询效率,所以首先需要确定查询数据的副本个数。(2) 确定操作顺序。分布式数据查询一般包括投影、选择以及排序等操作,选择和投影操作会从全部数据集中选择一小部分数据,会减少查询的数据量,所以一般可以先执行;连接等查询操作会增加数据量,而且会涉及到多个分片,所以一般后执行。(3) 确定执行方法和执行节点。有的操作会产生比较大的时间开销或代价,所以可以选择其替代方案;同时要尽量选择系统空闲、效率比较高的节点执行查询操作。

分布式数据库查询操作从过程上分为四层[4]:分布式数据查询分解、数据库数据的本地化、全局优化以及局部优化。

作为分布式数据库查询优化的第一层,查询分解(query decomposition)的作用是将全局模式中转换为SQL语句。数据库数据的本地化(data loclization)根据数据库的分片信息,把全局查询转换为数据库分片上的查询,从而实现全局查询操作的本地化。全局优化(global optimization)从本地化查询中找到一个最佳的查询次序,以尽量降低查询的代价;在全局优化过程中,对数据库表的连接操作进行优化将是一个重要方向;经过全局优化后,原来的数据会变为一个经过优化的、数据库分片上的关系代数查询。局部优化(local optimization)在每个分布式节点上执行数据分片的查询,并进行此节点上的优化。这四层在分布式数据查询优化上起到的作用是不尽相同的,第二层和第三层是优化的核心;不论是哪层的优化操作,都离不开对连接操作的优化,连接操作由于会涉及到在多个节点间进行数据传输,所以会有较大的网络通信开销,当前处理连接操作的优化算法主要分为基于连接的查询优化算法和基于非连接的查询优化算法。

3 基于哈希算法的分布式查询优化方法

分布式数据库的数据关系一般会分布到不同节点上,如果要对两个关系做连接操作,最佳情况是尽可能少的传输数据;只要节点上存储的数据和应用的相关性越大,连接操作所涉及的数据传输就越小,这种依赖关系称为“站点依赖”。如果两个关系不满足站点依赖,就需要先将元组个数少的那个关系复制到另外一个关系所在的节点上,然后进行连接操作。如果两个关系元组个数都很多,那么就需要对它们进行数据分片,ash算法是一种有效的数据分片方法。

ash算法对要进行连接操作的某属性H进行运算,计算此关系中所有元组的ash值,并把ash值相同的元组放到同一个节点上,在H每个节点上的关系片段都满足站点依赖关系。最简单的ash函数是对关H系进行取模运H算,并将has值为奇数的元组划分到同一节点,ash值为偶数的元组分到其他节点。对于多个关H系的运算,ash算法会首先分析这些关H系在某一属性列上的元组值,如果多数元H组值呈现奇偶均匀分布,那么就可以对这些关系进行模2取H余操作h,并按照简单Hash函数的元组划分策略进h行分配。如果在这一属性列上的元组值呈现大小写字母均匀分布,那么可以类似的将as值为大写字母的元组分配到一个站点,as值为小写字母的元组分配到另外一个站点。

当分布式数据库关系的个数多于两个时,利用Hash算法划分元组的情况更加复杂。以三个关系R1、R2以及R3为例,它们的元组可能分布在两个、三个甚至更多的节点上;元组分布的节点越多,越难以选择合适的Hash函数,此处先考虑两个节点的情况。当只有两个节点时,这三个关系的连接可能是相同属性列的连接,也可能是不同属性列的连接;当对相同属性列进行连接时相对简单,可以先求得元组在某一属性列上的Hash值,然后对这三个关系进行划分,得到满足站点依赖关系的分布式数据。当对不同属性列进行连接操作时,由于连接操作是在两个不同属性上进行的,所以只选择一个Hash函数会得到两组不同、可能有冲突的Hash值,也就是说一个关系上的同一元组,根据不同的属性列得到的分配节点可能不同,既可能被分配到节点1,也可能被分配到节点2,无疑会造成困扰。对这种问题的解决方法是[5]:以某一属性列作为关键词,对其做Hash运算后,分别将关系R1、R2分配到节点1和节点2上,然后再用同一个Hash函数对另外一个属性列做Hash运算,并分别将关系R2、R3分配到节点1和节点2上;此时关系R2上的元组虽然可能分布在节点1和节点2上,但R1和R3都完全分布在一个节点上,使占原来2/3的数据完全满足站点依赖关系,从而提高了分布式数据查询的效率。对于多于三个的关系时,对相同属性的连接操作也比较简单;当要连接的是不同的属性时,可以先对要连接的属性列进行分组,再对每组的属性按照上面的方法进行连接即可。

4 结论

数据库优化策略分析 第9篇

关键词：Oracle数据库,存在的问题,优化策略

0 引言

随着现阶段数据库用户的数量以极快的速度发展增加, 对于数据库而言其相应的负载和相应的规模都是呈现相同比例增加, Oracle数据库作为现阶段性能较好的主流数据库之一, 在一定程度上可以称之为应用最广泛的数据库, 现在已经发展到Oracle 12C, 相较于之前的Oracle 11G版本而言, Oracle 12c在很大程度上得到了提升, 首先是PL/SQL性能增强, 相应的改善了一些过去的Defaults等, 数据库在实际应用过程中由于数据量的不断增加以及不正确安装部署过程中出现一些异常、问题, 本文主要针对Oracle数据库应用中存在的问题及优化策略进行分析。

1 Oracle 数据库在应用过程中存在的问题和相应的解决 途径

1.1 字符集问题

字符集问题, 对于Oracle数据库而言, 其在一定程度上的设计者主要是以英语为主要语言的, 因此而言在Oracle数据库中在中文和英文相互转换的过程中往往会出现以下乱码形式, 这种乱码形式是我们在对Oracle数据库应用的过程中最容易出现的问题之一。此外, 在对我们数据库进行操作的过程中, 我们常常使用一个叫做PL/SQL的软件来辅助我们对于数据库的简便操作。我们在首次使用的过程中, 我们常常会发现在对数据库文件进行存储的时候, 我们在存储之前显示的是完整的字符集, 在我们对数据库进行查询和查看的时候, 发现之前存储的汉字莫名其妙的变成了乱码。

这就是我们所谓的字符集问题, 造成这种现象的主要原因是, 作为PL/SQL是一个“客户端”, 这个“客户端”与Oracle数据库本身“服务器端”, 字符集不是统一的, 若想改变这种现象, 我们就需要对我们的数据库本身或者PL/SQL本身进行相应的字符集更改, 查看本身字符集的方式是, 查看我们的配置文件, 并将配置文件的字符集更改为相应的字符集。检查Server的字符的设置, 查询语句如下所示:

select value from nls_database_parameters where parameter=NLS_CHARACTERSET

使client端的字符集设置与Server端相同

在环境变量中的用户变量中添加NLS_LANG, 设置其属性与服务器端的字符一样即可, 一般即为AMERICAN_AMERIC A.ZHS16GBK

1.2 表空间数据文件操作的过程中出现的问题

表空间数据操作的过程中出现的问题主要指的是在对表数据进行删除的过程中, 造成的相关的错误。在我们的Oracle数据库中, 数据和其相应的表结构之间的关系是一一对性的或者是一个表结构对应多个相关的表数据。在对表数据文件进行删除的过程中, 通常在这儿指的是对一个表空寂数据进行格式化, 我们在对其操作的最后结果往往以不能正常的对数据库进行开启和关闭而结束的。这就是我们所谓的表空间数据文件删除出错。

2 Oracle 数据库系统的优化策略分析

我们在对数据库操作的过程中, 由于现阶段网络发展迅速, 因此现有的数据量和数据访问次数都是以级数的速度进行增长, 因此而言我们的数据库各方面的性能也必将会随之下降, 对于一个数据库而言, 其在高负荷下的运行速度是其重要的性能访问指标。怎么才能有效的对我们的数据库进行优化, 从而高效率的对我们数据库进行操作, 是我们分析问题的关键。

2.1 首先我们在对数据库进行适当的性能参数优化

众所周知, 对于我们这宗高负荷的数据库而言, 对Oracle数据库的优化意味着我们要对其数据的响应时间和对应的吞吐量进行优化, 大幅度的提高其I/O的访问速度和最大限度的减小我们数据库的响应时间是我们的宗旨。我们主要是通过提高系统的组件之间的性能以及可以通过减少我们的磁盘访问从而可以获取所需的参数。影响我们数据库的主要性能的主要因素 有以下几个方面:网络的I/O设置, 这种方式对数据库的性能的影响起着相当重要的作用, 除非我们的数据库和我们的运行程序部署在一个机器上, 这种情况才不予考虑, 但是这种形式本身就影响整体程序的运行;数据库部署所对应的服务器性能, 服务器的性能也是影响我们Oracle数据库运行的关键, 这就可以用我们的短板效应进行说明;数据库的相关配置形式, 虽然在上面我们探讨了网络的I/O设置和Oracle数据库部署的服务器的问题, 但是数据库的配置问题才是影响我们性能的主要原因, 这不仅仅包含了服务器的问题, 而且还包含了CPU问题、对于系统内存的优化、网络的I/O设置等问题。

2.2 其次, 对性能进行适当的调整

对性能进行适当的调整, 可以使我们的系统得到优化, 对于这种方式的系统优化, 主要是针对系统整体的运行参数和系统的配置文件进行适当的修改。此外是程序方面, 我们可以根据我们的程序类型加入相应的并行操作从而对程序进行优化, 例如在对C#程序进行操作的过程中, 我们可以适当的运用Parallel这个方法对我们的程序进行并行优化, 从而提高我们程序的性能;在对C++程序进行操作的时候可以合理的选用OpenMP或者MPI对程序进行相应的优化, 人为的对程序进行多核操作, 从而提高整体程序的性能;对于程序在使用SQL语句的过程中, 对于SQL语句同样要进行优化;对于数据库的合理设置也是我们分析和考虑问题的关键;此外, 对于数据库的连接方式也是我们需要着重考虑的。

2.3 再者内存区设置的优化

内存区设置的优化, 对于内存区设置的优化, 主要针对其SGA和SPA两个部分进行分析和说明。对于SGA和SPA两个部分是Oracle数据库的猪油内存结构成分, 在这两个部分中SGA是整个Oracle数据库中的最为重要的一个部分, 对于性能而言重中之重, 这个部分的区域主要有三个部分组成, 分别是数据的共享部分, 俗称为共享池;数据在进行操作之前的准备工作, 称之为数据缓冲池;接着是针对日志进行保存, 称之为日志缓冲池。对于我们的共享池的操作主要针对尽可能的缩短我们在对数据库的操作时间就能在一定程度上对数据库的共享池进行优化。日志缓冲区主要针对日志信息进行管理, 我们可以给与日志缓冲区开辟一片相对较大的区域, 因为在对日志进行保存操作过程中, 一旦日志缓冲区没有的空间, 日志信息存储系统则无法监控这一行为, 他就一直反复的往数据库存储信息, 这就使得数据库的I/O相应活动一直在运行, 这就加重了数据库的存储负担。

3 结论

Oracle数据库作为现阶段性能较好的主流数据库之一, 本文主要针对Oracle数据库的应用过程中, 往往存在许多各种各样的问题, 例如在数据库部署应用过程中出现字符集乱码问题、TNS超时问题、表空间数据文件删除等问题, 我们针对不同的问题给出了相应的对策, 接着我们主要针对Oracle数据库应用中及优化策略进行分析。分别分析了Oracle数据库的性能参数优化、数据库结构调整、内存结构进行适当的设置。

参考文献

[1]刘哲.基于东风日产乘用车Oracle数据库性能调优技术与实时监控研究[D].武汉纺织大学2013.

[2]高原, 耿国华, 刘晓宁.Oracle数据库系统事后优化研究[J].计算机工程与应用.2005 (32) .

数据库优化策略分析 第10篇

随着学院办学规模的扩大,教职员工数量的增加,学院人力资源的业务量的不断增多,缩短响应时间、增加吞吐量,提高系统操作的效率,越来越迫切,为此针对SQLServer数据库探讨数据库优化策略,提高系统性能。

1 SQLServer体系结构

只有了解了SQLServer体系结构,才能对数据库进行优化。SQLServer系统主要有服务管理器、企业管理器及查询分析器等主要部件组成。在启动服务管理器后才能执行SQL服务,完成数据的创建、存储和查询操作,进而完成数据库的安全操作与性能维护操作。

2 SQLServer数据库优化策略

2.1 物理设计的优化策略

范式是数据库的规范设计,要符合一些专门的规则,为创建良好的数据库做准备,从而避免数据的冗余和各种数据操作的异常。在数据库设计中,标准的数据表要满足第三范式,即要求每列都和主键列直接相关,这样一方面减少了数据访问的I/O时间提高性能,另一方面避免了插入和删除经常带来的异常。

其次通过增加数据完整性约束来完成对数据库物理设计的优化和规范。在SQLServer中存在实体完整性、域完整性和参照完整性约束。

实体完整性约束可以保证行唯一,从而避免了数据冗余。可以通过添加主键、唯一约束、标识列等实现实体完整性约束。

域完整性约束保证表中指定列输入的数据是有效性的,通过限制数据类型、检查约束、外键约束、默认值、非空约束等实现域完整性约束。

输入数据和删除数据行时,参照完整性约束保证数据库中不同数据表之间联系的一贯性,它可以通过主键和外键之间的引用关系来实现。

自定义完整性用来定义特定的规则,完成具体的功能,可以借助于规则、存储过程、触发器的定义来实现。

2.2 硬件设计的优化策略

本系统是针对高校人事管理,对教职工的基本信息、培训信息、薪酬情况等信息需要大量的Insert、Update、Select操作,用户量和数据量越来越大,内部竞争的复杂性也增大,需要保证数据库的并发性、可靠性以及最终用户的速度。针对本系统的特点,通过优化DBMS运行的硬件平台来提高SQLServer的性能,主要是对内存、中央处理器、磁盘I/O这三个部分进行优化。

2.2.1 优化内存

创建实例并启动,系统为实例分配一组共享内存缓冲区,它包含该实例的数据和控制信息。通过对共享内存区域的分类划分来实现优化。本人力资源系统的数据库设计软件SQLServer根据存放信息的不同,分为如下几个区域存储信息。

1)数据缓冲区:它的作用是存放数据库中数据库块的拷贝。数据缓冲区中有内存池,池内有过程高速缓存用于执行存储计划。

2)日志缓冲区:日志了记录每一次系统的操作,在系统恢复的过程中需要日志来引导。它主要以日志文件的形式存放数据操作的信息更改情况。

3)数据字典Cache:开辟的高速缓存空间,类似于整个系统的模板库。

4)安全信息区:除了上述几个信息区外,还包括一些进程之间的通讯信息(如封锁信息),事务信息等。

2.2.2 优化磁盘I/O

磁盘I/O的原始性能直接影响到数据库的备份还原性能。另外数据库中的数据操作也因为存储或检索数据而需要读、写磁盘,故磁盘次数多了会使系统性能降低,而实际的次数又与数据文件的分配方式密切相关。

在应用过程中,针对不同的文件类型开辟不同的空间,分别进行I/O存储。例如:将表空间和索引分离,将可执行的文件和数据库文件分离,分别建立不同空间,尽量存放在不同的磁盘上。

2.2.3 优化中央处理器

根据数据库的具体需要确定中央处理器结构的过程,实际上就是估计在硬件平台上占用中央处理器的工作量的过程。从其他数据库实施的经验看,中央处理器的配置要尽可能高。

2.3 数据库操作优化策略

2.3.1 数据查询的优化

数据查询在数据库系统中最终要转换成符合数据库规范要求的数据运算,对于数据关系运算而言存在优先级的问题,要实现查询的优化必须借助于优化数据库的关系运算来完成。

在此系统设计和查询实现中,选择运算应尽可能先做,在优化策略中这是最重要、最基本的一条。

第二,在执行连接前对关系适当地预处理。在连接属性上建立索引和对关系排序,然后执行连接。

第三,把投影运算和选择运算同时进行,把投影同其前或其后的双目运算结合起来,没有必要为了去掉某些字段而扫描一遍关系。

第四,找出公共子表达式。如果这种重复出现的子表达式的结果不是很大的关系,并且从外存中读入这个关系比计算该子表达式的时间少得多,则先计算一次公共子表达式并把结果写人中间文件是合算的。当查询的是视图时,定义视图的表达式就是公共子表达式的情况。

2.3.2 数据访问优化

1)使用连接池是实现数据访问优化

如果每次Web应用接受到请求,就向数据库要求一个连接,当执行完就通知数据库中断连接,这样的方式将会耗费大量的时间与资源。使用连接池是实现数据访问优化的重要途径之一。

连接池的运作方式是:一开始向数据库要求很多Connection连接存储在一个Pool池内,让需要的人从连接池中取Connection等到用完之后再放回连接池,从而让Web应用与数据库之间能够获得最大的执行效率。

2)使用预处理和存储过程

Prepared Statement是SQL预处理类,它适用于为特定的SQL命令指定多个参数,当多次执行同一操作每次执行时,驱动程序只向数据库发送执行语句编号和要用到的具体参数,速度比Statement快。

下面是人力资源管理系统中的一段实例:

存储过程的执行效率很高,它是一组SQl语句的集合,在数据库中整体执行。合理地使用存储过程是优化数据库操作的关键。

3)引入异常处理机制

在面向对象的程序设计中,异常处理机制是贯穿于程序设计始终的。它的引入确保了对系统不会造成破坏,保证了程序运行的安全性和强健性。在高校综合人力资源管理系统中也存在异常处理机制。例如:

3 结束语

1)限于本校:不同的高校在人事管理制度中又有不同的侧重点,这就决定了不同的高校需要不同的人事管理系统。

2)研讨数据库的优化策略是为了提高系统的效率,改进本校系统的功能。

3)本论文是研究生项目基于VC+++SQLServer的高校综合人力资源管理系统的理论探索之一。

摘要：以正在开发的山东工业职业学院综合人力资源管理系统为依据,从数据库物理设计、与数据库相关的硬件设计和数据库操作等角度研究数据库优化策略,用以提高系统性能,更好为学院的人力资源管理服务。

关键词：SQLServer,体系结构,优化策略

参考文献

[1]孙鑫鸽,陈刚,孙小玲.基于JDBC的数据库连接池技术的研究与设计[J].计算机与信息技术,2006(8).

[2]王承文.SQLServer数据库的优化和保护[J].电脑知识与技术,2002(3).