oracle 数据库调优简介

以前开发数据库都是拿到手就开始利用手里的工具开始设计数据库的表结构，然后导入表到数据库中建立数据库，从来不考虑数据优化的问题。现在就吃足了这方面的苦头了。现在开发的系统当初设计的时候没有考虑后期数据的变化，没有在设计阶段做数据库的优化设计。结果现在导致数据库操作速度跟不上系统要求。服务器经常当机！迫切要求对数据库进行优化设计，提高数据库的性能。刚刚看到篇文章觉得还不错就摘下来来。没地方放，就放博客里把，好东西要大家分享。嘿嘿!

读完文章总结了一下数据库调优主要注意以下几点（暂时的，以后发现会添加的）：

1. 将表数据和索引数据分开表空间存储。

2. 显式为主键列建立反向键索引

3. 将子表的外键列的索引改为压缩型

4. 建立满足需求的复合键索引

5. 用户SQL质量

在条件有限的条件下，我们可以调整应用程序的SQL质量：

5.1. 不要进行全表扫描（Full Table Scan）：全表扫描导致大量的I/O

5.2. 尽量建好和使用好索引：建索引也是有讲究的，在建索引时，也不是索引越多越好，当 一个表的索引达到4个以上时，ORACLE的性能可能还是改善不了，因为OLTP系统每表超过5个索引即会降低性能，而且在一个sql 中， Oracle 从不能使用超过 5个索引；当我们用到GROUP BY和ORDER BY时,ORACLE就会自动对数据进行排序,而ORACLE在INIT.ORA中决定了sort_area_size区的大小,当排序不能在我们给定的排序区完成时,ORACLE就会在磁盘中进行排序,也就是我们讲的临时表空间中排序, 过多的磁盘排序将会令 free buffer waits 的值变高,而这个区间并不只是用于排序的,对于开发人员我提出如下忠告:

5.2.1. select,update,delete 语句中的子查询应当有规律地查找少于20%的表行.如果一个语句查找的行数超过总行数的20%,它将不能通过使用索引获得性能上的提高.

5.2.2. 索引可能产生碎片,因为记录从表中删除时,相应也从表的索引中删除.表释放的空间可以再用,而索引释放的空间却不能再用.频繁进行删除操作的被索引的表,应当阶段性地重建索引,以避免在索引中造成空间碎片,影响性能.在许可的条件下,也可以阶段性地truncate表,truncate命令删除表中所有记录,也删除索引碎片.

5.2.3. 在使用索引时一定要按索引对应字段的顺序进行引用。

5.2.4. 用（+）比用NOT IN更有效率。

6. 对于大表，可以考虑创建分区表，分区表有范围分区、散列分区、列表分区和散列分区几种，通过它可以达到化大表为小表的目的。

7. 考虑适量的数据冗余，如一个业务表有一个审批状态，审批需要经过多步，每一步对应审批表的一条记录，最后审批的那条记录决定了业务的状态。我们大可在业务表中存放一个审批状态的标志，以取消每次需要通过关联审批表获取业务审批状态的复杂的关联表查询。

8. 不要做太多的关联表查询，一些几乎不发生数据变动的表码表，如性别，学历，婚姻状态等表码表，可以考虑在应用程序启动时一次性地下载到应用程序的内存中缓存起来，在从数据库获取结果集后，再由程序利用这些缓存的表码表数据来翻译这些表码字段，而不要在数据库中通过表间的关联查询方式来翻译这些字段

9. 常看到一些令我瞠目的设计：在需要进行频繁DML(INSERT,UPDATE,DELETE)操作的表的某些基数低的字段（如性别，婚姻状态）上创建位图索引。位图索引是好东西，但它是有使用范围的，在OLTP系统中，需要进行频繁DML操作的表中不应该出现位图索引，位图索引只适用于几乎不进行DML操作，只进行查询的DSS系统中。此外，聚簇和索引组织表也都更适合DSS系统，而非OLTP系统。    

查看原文：

数据库调优：

sql质量的保证: