60-80% of database performance issues are related to poorly performing SQL。60-80%的数据库性能问题要归结于生产中糟糕的SQL语句！
以此一文来总结笔者近10多年来的工作经验并基于最主要的也是最有效的对于Oracle数据库中的RBO、CBO、索引、WHERE条件进行解说同一时候配以大量案例来帮助读者从此文中学到的相关的理论知识高速的运用到其正在从事的生产环境中的优化过程中去。
优化的理论基础
通过Select Count(?)进入优化之旅
不看百度或者GOOGLE说出以下3者的差别？
SELECT COUNT (*)
SELECT COUNT(1)
SELECT COUNT(字段名）
SELECT Count(?
)的知识
ORACLE的优化器
要说PLSQL优化，我们先须要来好好说一下Oracle优化器的知识：
优化器的优化模式
CBO模式
RBO模式
一起来看看oracle优化器的发展历程
所以。我们知道ORACLE10后開始默认使用CBO。在CBO时ORACLE会自己主动来选择最优的运行计划，有时我们会觉得：这个应该走索引更好啊。可是对于CBO来说。一个FULL TABLE ACCESS反而比索引更有效。
因此。在CBO的模式下，我们须要做的就是：
- 做好数据库信息的相关统计
- 合理建设我们的索引
- 优化我们的SQL
让我们从索引的基本知识下手吧
索引是不须要改动SQL最直接带来性能提升的利器，何时该建索引，怎么建？怎么样让你的索引更合理？
索引按内部结构分类
索引按功能分类
索引按索引对象分类
建立索引的方法论
上面介绍了这么多索引的分类，以下来讲讲建立索引的方法论吧。大家可能较关心这个。由于这个是经验总结也是实战实用的利器哈。
不建议建立索引的情况
索引非常奇妙，可是索引不是万能，有时你建了索引也等于没用或者是白建、作无用功，为什么呢？我们看下去。
索引不会生效的情况
所以索引不要乱建，有时建了也是白建。为什么呢？来看看以下的案例分析吧：
以案例来说明
PLSQL优化>一个不走索引的优化案例
这个样例说明了。假设你有一字參于WHERE条件查询的字段。可是它參于了运算符，因此它在ORACLE的内部运行计划中是不会走索引的。因此我们做了一个小小的变化。效率提升了多少倍？5.3倍，530%。呵呵！
以上例我们能够为建立索引作一个总结。
建立索引的总结
Table Analyze
Analyze Table VS DBMS_STATS
Import & Export
说到Import & Export命令，大家会说。。。哎，这个不是非常easy，就是：imp username/pwd@oraid file=path 吗？嘿嘿。。
。
试想：
- 你须要导入一个8GB左右的.dmp文件进入数据库
- 你须要将一个库，当中含有至少30张表而且每张表都超过1200万条记录的数据进入一个.dmp文件
然后你去试试看这个耗时。
Import的常规做法
这是一个真实的案例。我们在CCC即世界著名车险公司项目中。我们定期会和CCC芝加哥总部同步一个8GB左右的.dmp文件进入我们的数据库，由于安全原因因此须要依靠.dmp交换文件的形式于零晨同步至中国的数据库，而且在T+1第二天早晨的8：00前完毕同步。
于是。我们的DBA開始来了。。
。。。
从零晨到第二天早上8：00，硬是没有导完，一查，数据库中session已经超时了，连续2天还是这样。
于是，我们把原有的语句稍稍作了一下变化：
仅仅是把原来的一句imp折成了2条：
- 第一条，仅仅导数据，不导索引。而且设置成10000条数据一次commit，同一时候设置了一个缓冲池
- 第二条，仅仅导索引。不导数据。而且设置成10000条数据一次commit，同一时候设置了一个缓冲池
结果让人惊叹。。。发觉最后仅仅用了40分钟不到，两条语句所有运行完毕。完毕了导入。。
。事实上这个原因我能够用以下2个样例来说明：
- 一个含有8GB文件内容的文件夹，用FTPclient下载，你会发觉似乎永远等不到头，几小时就这样耗着，然后你改成先把这个文件夹打成一个压缩包，然后再用FTPclient 下载。几十分钟就能搞定。
-
你用JDBC写一个FOR循环插入100万条记录。
。结果是ORACLE直接爆掉。而你採用批量提交。。。结果是惊人的！
事实上我们当时所做的折分，原理如同上述两个案例，是一样的道理，降低IO读写，设置缓冲，批量提交。假设你的事务太大。
。。。。
以案例来说明PLSQL的优化
PLSQL优化-SELECT IN 与SELECT EXISTS
这边提高了多少？光看IO就知道提高了多少了，呵 呵，非常好玩吧？再来！
PLSQL优化-SELECT IN的几种优化
PLSQL优化-SELECT IN、OR、UNION的互转
看看3次改动，最后一次。提升了多少倍？11.2850-0.0261再除以0.0261=431.375，431.375倍。。。。。。一条SQL啊。
。。
在寸土寸金的互联网应用中，单条SQL提高了431.375倍。。。这是什么概念。！！
你好讨厌。！！再来。！！
PLSQL优化-分页语句中增加索引的优化
以下是一条分页语句，我们对created_date做一个索引，等。。。。。。等等等，这边的索引不是一般的索引。我们把图形化工具建的索引翻译成SQL：
create index IDX_WAREHOUSE_CT on T_WAREHOUSE(CREATED_DATE DESC); 我们这个表是一个含有1000万条记录的表，仅此一招。整个SQL查询提高了300%-340%
PLSQL优化-INNER JOIN VS WHERE
PLSQL优化-WHERE语句优化要点
注意以下这个样例。仅仅是WHERE条件后的顺序上下颠倒一下。就提高了10倍的效率，呵呵。
WHERE语句中选择最有效的表名顺序
好玩吧！
！！再来！
！！
PLSQL优化-用UNION代替OR
看看以下这个样例吧：
是不是写SQL时略微注意一下。。。这个效率。
。这个性能 。。。123%。
123%的提高啊。
PLSQL优化>共享SQL
前面我们用好几个实例说了一下PLSQL中最主要的一些性能上能够带来的提升。这边我们须要提一下ORACLE自带的一个缓冲SQL结果集命中率的工具
所以。我们在写SQL时要用JAVA的PreparedStatement，要用:1这种东西来做传值，由于ORACLE是自带SQL缓冲池的，另外在此要多说一句的是。尽管ORACLE10后開始带有ASM（自己主动内存管理）。但有时ASM不是万能，对于一些大形站点，有时我们的DBA是须要手工去调整ORACLE的SGA，即：
因此，这对我们的ORACLE DBA来说提出了更高的要求。
PLSQL优化的基础掌握了上述几点，基本能够让你的系统性能提高2位数-3位数。兴许感兴趣的读者还能够继续去看：
怎样自学
对于ORACLE的PLSQL相关调优该怎样自学呢？
是不是非常自虐哈。
那我们就用著名的Opensource界的一句铭言：play by yourself, play with it。
用中文来说那就是：自虐着并快活着。
要成为“东方不败。