个人总结:
1.尽量减少sql语句调用的次数,避免在循环语句中执行数据库操作.
2.尽量减少多表的联查,用空间换时间,跟业务逻辑紧密绑定.
3.适当增加插入工作量,提高查询效率.根据接口的访问频率调整表结构
4.多使用联合主键和复合主键
5.分页返回查询结果,限制每次查询数量
别人的经验:
一.首先对于硬件及数据库配置方面来说,可以考虑以下几方面：

1、升级硬件
　　2、扩大服务器的内存
　　3、增加服务器CPU个数
　　4、对于大的数据库不要设置数据库自动增长，它会降低服务器的性能

二.软件方面，主要是sql优化方面

1、建立适当的索引（至于为什么请参考为什么建立了索引可以提高效率）

2、避免在索引列上使用计算

WHERE 子句中，如果索引列是函数的一部分．优化器将不使用索引而使用全表扫描．
　　举例 :
　　低效：
　　SELECT … FROM DEPT WHERE SAL * 12 > 25000;
　　高效 :
　　SELECT … FROM DEPT WHERE SAL > 25000/12;

此时应建立基于函数的索引，例如：create index i_account_real_name on account(upper(real_name))

3、避免在索引列上使用 NOT

通常 ，我们要避免在索引列上使用 NOT, NOT 会产生和在索引列上使用函数相同的影响 . 当 ORACLE” 遇到 ”NOT, 他就会停止使用索引转而执行全表扫描 .

4、避免在索引列上使用 IS NULL 和 IS NOT NULL

避免在索引中使用任何可以为空的列， ORACLE 将无法使用该索引 ．对于单列索引，如果列包含空值，索引中将不存在此记录 . 对于复合索引，如果每个列都为空，索引中同样不存在此记录 . 如果至少有一个列不为空，则记录存在于索引中，举例 : 如果唯一性索引建立在表的 A 列和 B 列上 , 并且表中存在一条记录的 A,B 值为(123,null) , ORACLE 将不接受下一条具有相同 A,B 值（ 123,null ）的记录 ( 插入 ). 然而如果所有的索引列都为空， ORACLE 将认为整个键值为空而空不等于空 . 因此你可以插入 1000 条具有相同键值的记录 , 当然它们都是空 ! 因为空值不存在于索引列中 , 所以 WHERE 子句中对索引列进行空值比较将使 ORACLE 停用该索引 .

低效 : ( 索引失效 )
　　SELECT … FROM DEPARTMENT WHERE DEPT_CODE IS NOT NULL ;
　　高效 : ( 索引有效 )
　　SELECT … FROM DEPARTMENT WHERE DEPT_CODE >= 0;

5、避免返回不必要的行和列

在查询Select语句中用Where字句限制返回的行数,避免表扫描,如果返回不必要的数据，浪费了服务器的I/O资源，加重了网络的负担降低性能。如果表很大，在表扫描的期间将表锁住，禁止其他的联接访问表,后果严重。

6、SELECT 子句中避免使用 ‘ * ‘

ORACLE 在解析的过程中 , 会将 ‘*’ 依次转换成所有的列名 , 这个工作是通过查询数据字典完成的 , 这意味着将耗费更多的时间

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

8、使用batch处理

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

9、注意UNion和UNion all 的区别

UNION和UNION all均是对两个结果的取并集，但是union会对结果进行去重和排序，但是会牺牲性能，而union all 不会，所以若可以提前确认两个结果集中不会产生重复的内容，使用union all 最佳

10、WHERE 子句中的连接顺序

ORACLE 采用自下而上（自右向左）的顺序解析 WHERE 子句 , 根据这个原理 , 表之间的连接必须写在其他 WHERE 条件之前 , 那些可以过滤掉最大数量记录的条件必须写在 WHERE 子句的末尾

11、DISTINCT的使用

注意，在数据量大的时候，尽量不要使用，它同UNION一样会使查询变慢。因为Oracle需要对后面的所有字段进行排序，消耗性能

12、尽可能不使用游标，它占用大量的资源

13、将需要查询的结果预先计算好放在表中，查询的时候再SELECT

14、数据库有一个原则是代码离数据越近越好，所以优先选择Default,依次为Rules,Triggers, Constraint（约束如外健主健CheckUNIQUE……,数据类型的最大长度等等都是约束）,Procedure.这样不仅维护工作小，编写程序质量高，并且执行的速度快。

15、Between在某些时候比IN速度更快,Between能够更快地根据索引找到范围。用查询优化器可见到差别。 select * from chineseresume where title in (‘男’,’女’) Select * from chineseresume where between ‘男’ and ‘女’ 是一样的。由于in会在比较多次，所以有时会慢些。

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

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

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

19、尽量将数据的处理工作放在服务器上，减少网络的开销，如使用存储过程。存储过程是编译好、优化过、并且被组织到一个执行规划里、且存储在数据库中的 SQL语句，是控制流语言的集合，速度当然快。

20、不要在一句话里再三的使用相同的函数，浪费资源,将结果放在变量里再调用更快

21、SELECT COUNT(*)的效率教低，尽量变通它的写法，而EXISTS快.同时请注意区别： select count(Field of null) from Table 和 select count(Field of NOT null) from Table 的返回值是不同的。

22、分析select emp_name form employee where salary > 3000 在此语句中若salary是Float类型的，则优化器对其进行优化为Convert(float,3000)，因为3000是个整数，我们应在编程时使用3000.0而不要等运行时让DBMS进行转化。同样字符和整型数据的转换。

23、选择最有效率的表名顺序 ( 只在基于规则的优化器中有效 )

ORACLE 的解析器按照从右到左的顺序处理 FROM 子句中的表名， FROM 子句中写在最后的表 ( 基础表 driving table) 将被最先处理，在 FROM 子句中包含多个表的情况下 , 你必须选择记录条数最少的表作为基础表。如果有 3 个以上的表连接查询 , 那就需要选择交叉表 (intersection table) 作为基础表 , 交叉表是指那个被其他表所引用的表.

24、使用 DECODE 函数来减少处理时间

使用 DECODE 函数可以避免重复扫描相同记录或重复连接相同的表 .

25、用 TRUNCATE 替代 DELETE

当删除表中的记录时 , 在通常情况下 , 回滚段 (rollback segments ) 用来存放可以被恢复的信息 . 如果你没有 COMMIT 事务 ,ORACLE 会将数据恢复到删除之前的状态 ( 准确地说是恢复到执行删除命令之前的状况 ) 而当运用 TRUNCATE 时 , 回滚段不再存放任何可被恢复的信息 . 当命令运行后 , 数据不能被恢复 . 因此很少的资源被调用 , 执行时间也会很短

26、尽量多使用 COMMIT

只要有可能 , 在程序中尽量多使用 COMMIT, 这样程序的性能得到提高 , 需求也会因为 COMMIT 所释放的资源而减少 :
　　COMMIT 所释放的资源 :
　　a. 回滚段上用于恢复数据的信息 .
　　b. 被程序语句获得的锁
　　c. redo log buffer 中的空间
　　d. ORACLE 为管理上述 3 种资源中的内部花费

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

28、如果使用like进行查询的话，简单的使用index是不行的，但是全文索引，耗空间。 like ‘a%’ 使用索引， like ‘%a’ 不使用索引用 ，like ‘%a%’ 查询时，查询耗时和字段值总长度成正比,所以不能用CHAR类型，而是VARCHAR。对于字段的值很长的建全文索引。

29、一般不要用如下的字句: “IS NULL”, ” <> “, “!=”, “!> “, “! <“, “NOT”, “NOT EXISTS”, “NOT IN”, “NOT LIKE”, and “LIKE ‘%500′”，因为他们不走索引全是表扫描。也不要在WHere字句中的列名加函数，如Convert，substring等,如果必须用函数的时候，创建计算列再创建索引来替代.还可以变通写法：WHERE SUBSTRING(firstname,1,1) = ‘m’改为WHERE firstname like ‘m%’（索引扫描），一定要将函数和列名分开。并且索引不能建得太多和太大。NOT IN会多次扫描表，使用EXISTS、NOT EXISTS ，IN , LEFT OUTER JOIN 来替代，特别是左连接,而Exists比IN更快，最慢的是NOT操作.如果列的值含有空，以前它的索引不起作用，现在2000的优化器能够处理了。相同的是IS NULL，“NOT”, “NOT EXISTS”, “NOT IN”能优化她，而” <> ”等还是不能优化，用不到索引。

30、整合简单 , 无关联的数据库访问

如果你有几个简单的数据库查询语句 , 你可以把它们整合到一个查询中 ( 即使它们之间没有关系 )

31、删除重复记录

最高效的删除重复记录方法 ( 因为使用了 ROWID) 例子：DELETE FROM EMP E WHERE E.ROWID > (SELECT MIN(X.ROWID) FROM EMP X WHERE X.EMP_NO = E.EMP_NO);

32、MIN() 和 MAX()能使用到合适的索引

33、用 Where 子句替换 HAVING 子句

避免使用 HAVING 子句 , HAVING 只会在检索出所有记录之后才对结果集进行过滤 . 这个处理需要排序 , 总计等操作 . 如果能通过 WHERE 子句限制记录的数目 , 那就能减少这方面的开销 .

34、 使用表的别名 (Alias)

当在 SQL 语句中连接多个表时 , 请使用表的别名并把别名前缀于每个 Column 上 . 这样一来 , 就可以减少解析的时间并减少那些由 Column 歧义引起的语法错误 .

35、 用 EXISTS 替代 I N 、 用 NOT EXISTS 替代 NOT IN

在许多基于基础表的查询中 , 为了满足一个条件 , 往往需要对另一个表进行联接 . 在这种情况下 , 使用 EXISTS( 或 NOT EXISTS) 通常将提高查询的效率 . 在子查询中 ,NOT IN 子句将执行一个内部的排序和合并 . 无论在哪种情况下 ,NOT IN 都是最低效的 ( 因为它对子查询中的表执行了一个全表遍历 ). 为了避免使用 NOT IN , 我们可以把它改写成外连接 (Outer Joins)或 NOT EXISTS.

例子：

（ 高效 ） SELECT * FROM EMP ( 基础表 ) WHERE EMPNO > 0 AND EXISTS ( SELECT ‘X’ FROM DEPT WHERE DEPT.DEPTNO = EMP.DEPTNO AND LOC = ‘MELB’)

( 低效 ) SELECT * FROM EMP ( 基础表 ) WHERE EMPNO > 0 AND DEPTNO IN (SELECT DEPTNO FROM DEPT WHERE LOC = ‘MELB’ )

36、用 EXISTS 替换 DISTINCT ：

当提交一个包含一对多表信息 ( 比如部门表和雇员表 ) 的查询时 , 避免在 SELECT 子句中使用 DISTINCT. 一般可以考虑用 EXIST 替换 , EXISTS 使查询更为迅速 , 因为 RDBMS 核心模块将在 子查询的条件一旦满足后 , 立刻返回结果 . 例子：

( 低效 ): SELECT DISTINCT DEPT_NO,DEPT_NAME FROM DEPT D , EMP E WHERE D.DEPT_NO = E.DEPT_NO

( 高效 ): SELECT DEPT_NO,DEPT_NAME FROM DEPT D WHERE EXISTS ( SELECT ‘X’ FROM EMP E WHERE E.DEPT_NO = D.DEPT_NO ) ;

37、sql 语句用大写的 ；因为 oracle 总是先解析 sql 语句，把小写的字母转换成大写的再执行

38、在 java 代码中尽量少用连接符“＋”连接字符串！

39、用 >= 替代 >

高效 : SELECT * FROM EMP WHERE DEPTNO >=4

低效 : SELECT * FROM EMP WHERE DEPTNO >3

两者的区别在于 , 前者 DBMS 将直接跳到第一个 DEPT 等于 4 的记录，而后者将首先定位到 DEPTNO=3 的记录并且向前扫描到第一个 DEPT 大于 3 的记录 .

40、用 UNION 替换 OR ( 适用于索引列 )

通常情况下 , 用 UNION 替换 WHERE 子句中的 OR 将会起到较好的效果 . 对索引列使用 OR 将造成全表扫描 . 注意 , 以上规则只针对多个索引列有效 . 如果有 column 没有被索引 , 查询效率可能会因为你没有选择 OR 而降低 . 在下面的例子中 , LOC_ID 和 REGION 上都建有索引 .

高效 : SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE LOC_ID = 10 UNION SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE REGION = “MELBOURNE”

低效 : SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE LOC_ID = 10 OR REGION = “MELBOURNE”

如果你坚持要用 OR, 那就需要返回记录最少的索引列写在最前面 .

41、用 IN 来替换 OR

这是一条简单易记的规则，但是实际的执行效果还须检验，在 ORACLE8i 下，两者的执行路径似乎是相同的．

低效 :
　　SELECT …. FROM LOCATION WHERE LOC_ID = 10 OR LOC_ID = 20 OR LOC_ID = 30
　　高效：
　　SELECT … FROM LOCATION WHERE LOC_IN IN (10,20,30);

42、总是使用索引的第一个列

如果索引是建立在多个列上 , 只有在它的第一个列 (leading column) 被 where 子句引用时 , 优化器才会选择使用该索引 . 这也是一条简单而重要的规则，当仅引用索引的第二个列时 , 优化器使用了全表扫描而忽略了索引

43、用 WHERE 替代 ORDER BY

ORDER BY 子句只在两种严格的条件下使用索引 .
　　ORDER BY 中所有的列必须包含在相同的索引中并保持在索引中的排列顺序 .
　　ORDER BY 中所有的列必须定义为非空 .
　　WHERE 子句使用的索引和 ORDER BY 子句中所使用的索引不能并列 .

例如 :
　　表 DEPT 包含以下列 :
　　DEPT_CODE PK NOT NULL
　　DEPT_DESC NOT NULL
　　DEPT_TYPE NULL

低效 : ( 索引不被使用 )
　　SELECT DEPT_CODE FROM DEPT ORDER BY DEPT_TYPE
　　高效 : ( 使用索引 )
　　SELECT DEPT_CODE FROM DEPT WHERE DEPT_TYPE > 0

44、避免改变索引列的类型 .:

当比较不同数据类型的数据时 , ORACLE 自动对列进行简单的类型转换 .

假设 EMPNO 是一个数值类型的索引列 . SELECT … FROM EMP WHERE EMPNO = ‘123′

实际上 , 经过 ORACLE 类型转换 , 语句转化为 : SELECT … FROM EMP WHERE EMPNO = TO_NUMBER(‘123′)

幸运的是 , 类型转换没有发生在索引列上 , 索引的用途没有被改变 . 现在 , 假设 EMP_TYPE 是一个字符类型的索引列 .

SELECT … FROM EMP WHERE EMP_TYPE = 123 这个语句被 ORACLE 转换为 :

SELECT … FROM EMP WHERE TO_NUMBER(EMP_TYPE)=123
　　因为内部发生的类型转换 , 这个索引将不会被用到 ! 为了避免 ORACLE 对你的 SQL 进行隐式的类型转换 , 最好把类型转换用显式表现出来 . 注意当字符和数值比较时 , 　　ORACLE 会优先转换数值类型到字符类型

45、需要当心的 WHERE 子句 :

某些 SELECT 语句中的 WHERE 子句不使用索引 . 这里有一些例子 .
　　在下面的例子里 ,

(1) ‘!=’ 将不使用索引 . 记住 , 索引只能告诉你什么存在于表中 , 而不能告诉你什么不存在于表中 .

(2) ‘||’ 是字符连接函数 . 就象其他函数那样 , 停用了索引 .

(3) ‘+’ 是数学函数 . 就象其他数学函数那样 , 停用了索引 .

(4) 相同的索引列不能互相比较 , 这将会启用全表扫描 .

46、避免使用耗费资源的操作 :

带有 DISTINCT,UNION,MINUS,INTERSECT,ORDER BY 的 SQL 语句会启动 SQL 引擎 . 执行耗费资源的排序 (SORT) 功能 . DISTINCT 需要一次排序操作 , 而其他的至少需要执行两次排序 . 通常 , 带有 UNION, MINUS , INTERSECT 的 SQL 语句都可以用其他方式重写 . 如果你的数据库的 SORT_AREA_SIZE 调配得好 , 使用 UNION , MINUS, INTERSECT 也是可以考虑的 , 毕竟它们的可读性很强

47、优化 GROUP BY:

提高 GROUP BY 语句的效率 , 可以通过将不需要的记录在 GROUP BY 之前过滤掉 . 下面两个查询返回相同结果但第二个明显就快了许多 .

低效 :SELECT JOB , AVG(SAL) FROM EMP GROUP JOB HAVING JOB = ‘PRESIDENT’ OR JOB = ‘MANAGER’

高效 : SELECT JOB , AVG(SAL) FROM EMP WHERE JOB = ‘PRESIDENT’ OR JOB = ‘MANAGER’ GROUP JOB

48、操作符优化

1）IN 操作符

用IN写出来的SQL的优点是比较容易写及清晰易懂，这比较适合现代软件开发的风格。

但是用IN的SQL性能总是比较低的，从ORACLE执行的步骤来分析用IN的SQL与不用IN的SQL有以下区别：

ORACLE试图将其转换成多个表的连接，如果转换不成功则先执行IN里面的子查询，再查询外层的表记录，如果转换成功则直接采用多个表的连接方式查询。由此可见用IN的SQL至少多了一个转换的过程。一般的SQL都可以转换成功，但对于含有分组统计等方面的SQL就不能转换了。

推荐方案：在业务密集的SQL当中尽量不采用IN操作符。

2）NOT IN操作符

此操作是强列推荐不使用的，因为它不能应用表的索引。

推荐方案：用NOT EXISTS 或（外连接+判断为空）方案代替

3）<> 操作符（不等于）

不等于操作符是永远不会用到索引的，因此对它的处理只会产生全表扫描。

推荐方案：用其它相同功能的操作运算代替，如

a<>0 改为 a>0 or a<0

a<>’’ 改为 a>’’

4）IS NULL 或IS NOT NULL操作（判断字段是否为空）

判断字段是否为空一般是不会应用索引的，因为B树索引是不索引空值的。

推荐方案：

用其它相同功能的操作运算代替，如 a is not null 改为 a>0 或a>’’等。

5）不允许字段为空，而用一个缺省值代替空值，如业扩申请中状态字段不允许为空，缺省为申请。

6）建立位图索引（有分区的表不能建，位图索引比较难控制，如字段值太多索引会使性能下降，多人更新操作会增加数据块锁的现象）。

7）> 及 < 操作符（大于或小于操作符）

大于或小于操作符一般情况下是不用调整的，因为它有索引就会采用索引查找，但有的情况下可以对它进行优化，如一个表有100万记录，一个数值型字段A，30万记录的A=0，30万记录的A=1，39万记录的A=2，1万记录的A=3。那么执行A>2与A>=3的效果就有很大的区别了，因为A>2时ORACLE会先找出为2的记录索引再进行比较，而A>=3时ORACLE则直接找到=3的记录索引。

8）LIKE操作符

LIKE操作符可以应用通配符查询，里面的通配符组合可能达到几乎是任意的查询，但是如果用得不好则会产生性能上的问题，如LIKE ‘%5400%’ 这种查询不会引用索引，而LIKE ‘X5400%’则会引用范围索引。一个实际例子：用YW_YHJBQK表中营业编号后面的户标识号可来查询营业编号 YY_BH LIKE ‘%5400%’ 这个条件会产生全表扫描，如果改成YY_BH LIKE ’X5400%’ OR YY_BH LIKE ’B5400%’ 则会利用YY_BH的索引进行两个范围的查询，性能肯定大大提高