ORACLE数据库性能优化概述

实际上 为了保证ORACLE数据库运行在最佳的性能状态下 在信息系统开发之前就应该考虑数据库的优化策略 优化策略一般包括服务器 *** 作系统参数调整 ORACLE数据库参数调整 网络性能调整 应用程序SQL语句分析及设计等几个方面 其中应用程序的分析与设计是在信息系统开发之前完成的

分析评价ORACLE数据库性能主要有数据库吞吐量 数据库用户响应时间两项指标 数据库吞吐量是指单位时间内数据库完成的SQL语句数目 数据库用户响应时间是指用户从提交SQL语句开始到获得结果的那一段时间 数据库用户响应时间又可以分为系统服务时间和用户等待时间两项 即

数据库用户响应时间＝系统服务时间 ＋ 用户等待时间

上述公式告诉我们 获得满意的用户响应时间有两个途径 一是减少系统服务时间 即提高数据库的吞吐量 二是减少用户等待时间 即减少用户访问同一数据库资源的冲突率

性能优化包括如下几个部分

ORACLE数据库性能优化之一 调整数据结构的设计

这一部分在开发信息系统之前完成 程序员需要考虑是否使用ORACLE数据库的分区功能 对于经常访问的数据库表是否需要建立索引等

ORACLE数据库性能优化之二 调整应用程序结构设计

这一部分也是在开发信息系统之前完成 程序员在这一步需要考虑应用程序使用什么样的体系结构 是使用传统的Client/Server两层体系结构 还是使用Browser/Web/Database的三层体系结构 不同的应用程序体系结构要求的数据库资源是不同的

ORACLE数据库性能优化之三 调整数据库SQL语句

应用程序的执行最终将归结为数据库中的SQL语句执行 因此SQL语句的执行效率最终决定了ORACLE数据库的性能 ORACLE公司推荐使用ORACLE语句优化器（Oracle Optimizer）和行锁管理器（row level manager）来调整优化SQL语句

ORACLE数据库性能优化之四 调整服务器内存分配

内存分配是在信息系统运行过程中优化配置的 数据库管理员可以根据数据库运行状况调整数据库系统全局区（SGA区）的数据缓冲区 日志缓冲区和共享池的大小 还可以调整程序全局区（PGA区）的大小 需要注意的是 SGA区不是越大越好 SGA区过大会占用 *** 作系统使用的内存而引起虚拟内存的页面交换 这样反而会降低系统

ORACLE数据库性能优化之五 调整硬盘I/O 这一步是在信息系统开发之前完成的

数据库管理员可以将组成同一个表空间的数据文件放在不同的硬盘上 做到硬盘之间I/O负载均衡

ORACLE数据库性能优化之六 调整 *** 作系统参数

例如 运行在UNIX *** 作系统上的ORACLE数据库 可以调整UNIX数据缓冲池的大小 每个进程所能使用的内存大小等参数

lishixinzhi/Article/program/Oracle/201311/17687

26、MIN() 和 MAX()能使用到合适的索引。
27、数据库有一个原则是代码离数据越近越好，所以优先选择Default,依次为Rules,Triggers, Constraint（约束如外健主健CheckUNIQUE……,数据类型的长度等等都是约束）,Procedure这样不仅维护工作小，编写程序质量高，并且执行的速度快。

28、如果要插入大的二进制值到Image列，使用存储过程，千万不要用内嵌INsert来插入(不知JAVA是否)。因为这样应用程序首先将二进制值转换成字符串（尺寸是它的两倍），服务器受到字符后又将他转换成二进制值存储过程就没有这些动作: 方法：

Create procedure p_insert as insert into table(Fimage) values (@image)

在前台调用这个存储过程传入二进制参数，这样处理速度明显改善。

29、Between在某些时候比IN速度更快,Between能够更快地根据索引找到范围。用查询优化器可见到差别。

select from chineseresume where title in ('男','女') Select from chineseresume where between

'男' and '女' 是一样的。由于in会在比较多次，所以有时会慢些。

30、在必要是对全局或者局部临时表创建索引，有时能够提高速度，但不是一定会这样，因为索引也耗费大量的资源。他的创建同是实际表一样。

31、不要建没有作用的事物例如产生报表时，浪费资源。只有在必要使用事物时使用它。

32、用OR的字句可以分解成多个查询，并且通过UNION 连接多个查询。他们的速度只同是否使用索引有关,如果查询需要用到联合索引，用UNION all执行的效率更高多个OR的字句没有用到索引，改写成UNION的形式再试图与索引匹配。一个关键的问题是否用到索引。

33、尽量少用视图，它的效率低。对视图 *** 作比直接对表 *** 作慢,可以用stored procedure来代替她。特别的是不要用视图嵌套,嵌套视图增加了寻找原始资料的难度。我们看视图的本质：它是存放在服务器上的被优化好了的已经产生了查询规划的SQL。对单个表检索数据时，不要使用指向多个表的视图，直接从表检索或者仅仅包含这个表的视图上读，否则增加了不必要的开销,查询受到干扰为了加快视图的查询，MsSQL增加了视图索引的功能。

34、没有必要时不要用DISTINCT和ORDER BY，这些动作可以改在客户端执行。它们增加了额外的开销。这同UNION 和UNION ALL一样的道理。

select top 20 adcompanyname,comid,position,adreferenceid,worklocation,
convert(varchar(10),adpostDate,120) as postDate1,workyear,degreedescription FROM
jobcn_querydboCOMPANYAD_query ad where referenceID in('JCNAD00329667','JCNAD132168','JCNAD00337748','JCNAD00338345',
'JCNAD00333138','JCNAD00303570','JCNAD00303569',
'JCNAD00303568','JCNAD00306698','JCNAD00231935','JCNAD00231933',
'JCNAD00254567','JCNAD00254585','JCNAD00254608',
'JCNAD00254607','JCNAD00258524','JCNAD00332133','JCNAD00268618',
'JCNAD00279196','JCNAD00268613') order by postdate desc

35、在IN后面值的列表中，将出现最频繁的值放在最前面，出现得最少的放在最后面，减少判断的次数。

36、当用SELECT INTO时，它会锁住系统表(sysobjects，sysindexes等等)，阻塞其他的连接的存取。创建临时表时用显示申明语句，而不是

select INTO drop table t_lxh begin tran select into t_lxh from chineseresume
where name = 'XYZ' --commit

在另一个连接中SELECT from sysobjects可以看到 SELECT INTO 会锁住系统表，Create table 也会锁系统表(不管是临时表还是系统表)。所以千万不要在事物内使用它！！！这样的话如果是经常要用的临时表请使用实表，或者临时表变量。

37、一般在GROUP BY 个HAVING字句之前就能剔除多余的行，所以尽量不要用它们来做剔除行的工作。他们的执行顺序应该如下：select 的Where字句选择所有合适的行，Group By用来分组个统计行，Having字句用来剔除多余的分组。这样Group By 个Having的开销小，查询快对于大的数据行进行分组和Having十分消耗资源。如果Group BY的目的不包括计算，只是分组，那么用Distinct更快

38、一次更新多条记录比分多次更新每次一条快,就是说批处理好

39、少用临时表，尽量用结果集和Table类性的变量来代替它,Table 类型的变量比临时表好

40、在SQL2000下，计算字段是可以索引的，需要满足的条件如下：

a、计算字段的表达是确定的

b、不能用在TEXT,Ntext，Image数据类型

c、必须配制如下选项 ANSI_NULLS = ON, ANSI_PADDINGS = ON, ……

从外在条件来说，优化mysql涉及优化硬件、优化磁盘、优化 *** 作系统、选择应用编程接口等。

二、优化硬件

如果你需要庞大的数据库表(2G)，你应该考虑使用64位的硬件结构，像Alpha、Sparc或即将推出的IA64。因为MySQL内部使用大量64位的整数，64位的CPU将提供更好的性能。

对大数据库，优化的次序一般是RAM、快速硬盘、CPU能力。

更多的内存通过将最常用的键码页面存放在内存中可以加速键码的更新。

如果不使用事务安全(transaction-safe)的表或有大表并且想避免长文件检查，一台UPS就能够在电源故障时让系统安全关闭。

对于数据库存放在一个专用服务器的系统，应该考虑1G的以太网。延迟与吞吐量同样重要。

mysql的优化大的有两方面：

1、配置优化

配置的优化其实包含两个方面的： *** 作系统内核的优化和mysql配置文件的优化

1)系统内核的优化对专用的mysql服务器来说，无非是内存实用、连接数、超时处理、TCP处理等方面的优化，根据自己的硬件配置来进行优化，这里不多讲；

2)mysql配置的优化，一般来说包含：IO处理的常用参数、最大连接数设置、缓存使用参数的设置、慢日志的参数的设置、innodb相关参数的设置等，如果有主从关系在设置主从同步的相关参数即可，网上的相关配置文件很多，大同小异，常用的设置大多修改这些差不多就够用了。

2、sql语句的优化

1）  尽量稍作计算

Mysql的作用是用来存取数据的，不是做计算的，做计算的话可以用其他方法去实现，mysql做计算是很耗资源的。

2）尽量少 join

MySQL 的优势在于简单，但这在某些方面其实也是其劣势。MySQL 优化器效率高，但是由于其统计信息的量有限，优化器工作过程出现偏差的可能性也就更多。对于复杂的多表 Join，一方面由于其优化器受限，再者在 Join 这方面所下的功夫还不够，所以性能表现离 Oracle 等关系型数据库前辈还是有一定距离。但如果是简单的单表查询，这一差距就会极小甚至在有些场景下要优于这些数据库前辈

3）尽量少排序

排序 *** 作会消耗较多的 CPU 资源，所以减少排序可以在缓存命中率高等 IO 能力足够的场景下会较大影响 SQL的响应时间。

对于MySQL来说，减少排序有多种办法，比如：

通过利用索引来排序的方式进行优化

减少参与排序的记录条数

非必要不对数据进行排序

4）尽量避免 select

在数据量少并且访问量不大的情况下，select 没有什么影响，但是量级达到一定级别的时候，在执行效率和IO资源的使用上，还是有很大关系的，用什么字段取什么字段，减少不必要的资源浪费。

5）尽量用 join 代替子查询

虽然 Join 性能并不佳，但是和 MySQL 的子查询比起来还是有非常大的性能优势。MySQL 的子查询执行计划一直存在较大的问题，虽然这个问题已经存在多年，但是到目前已经发布的所有稳定版本中都普遍存在，一直没有太大改善。虽然官方也在很早就承认这一问题，并且承诺尽快解决，但是至少到目前为止我们还没有看到哪一个版本较好的解决了这一问题。

1SQL查询语句的重写，对于一个查询可以用多种查询语句实现，但不同查询语句的数据库执行计划是不同的，一旦不能够使用索引或造成较大的内存占用会导致性能下降，因此需要对查询语句进行重写优化，最典型的例子就是notin语句使用外连接方式实现来进行优化

2创建合理的索引结构，根据查询语句的中查询条件，在关系表上建立相应的索引，如B树索引和hash索引

3修改程序业务逻辑，有些功能如果使用SQL语句实现，不但SQL语句复杂，还将导致数据库的负担增加，因此可以将有些数据 *** 作的业务逻辑放到应用层进行实现，就是通过java编程实现

4修改数据库服务器相关参数，优化服务器性能

调整服务器内存分配。内存分配是在信息系统运行过程中优化配置的，数据库管理员可以根据数据库运行状况调整数据库系统全局区（SGA区）的数据缓冲区、日志缓冲区和共享池的大小；还可以调整程序全局区（PGA区）的大小。需要注意的是，SGA区不是越大越好，SGA区过大会占用 *** 作系统使用的内存而引起虚拟内存的页面交换，这样反而会降低系统。

---