ORACLE SQL 优化

动机：在应用系统开发初期，由于开发数据库数据比较少，对于查询SQL语句，复杂视图的的编写等体会不出SQL语句各种写法的性能优劣，但是随着数据库中数据的增加，系统的响应速度就成为目前系统需要解决的最主要的问题之一。

SQL执行过程：

1. 客户端请求服务端执行SQL语句
2. 服务端接收到语句，进行解析
3. 解析完成后，执行SQL语句
4. 获取数据，返回客户端

第二步：语句解析是指数据库的解析器对SQL的语法合法性进行判断，判断是否有语法上的问题
第三步：语句执行之前会判断需要执行的语句查询数据是否已经读取到数据缓冲区，如果有则返回，无则查询数据文件中数据，之后写入缓冲区并返回

语句解析

1. 查询高速缓存是否有解析过的SQL缓存，如果有就直接执行（硬解析），没有缓存的话，就会生成SQL执行计划，并加入缓存（软解析）
2. 查看语句是否有语法错误，不符合就报错
3. 查看语句中的“列”、“表”是否存在，不符合就报错
4. 获取读写锁，保证数据的安全性
5. 查看用户是否有访问权限
6. 数据库自带优化器优化SQL（优化程度远低于开发时优化）

常见的优化规则

• 表连接数
  连接的表越多，性能越差
  可能的话，将连接拆分成若干个过程逐一执行
  优先执行可显著减少数据量的连接，既降低了复杂度，也能够容易按照预期执行
  如果不可避免多表连接，很可能是设计缺陷
  外链接效果差，因为必须对左右表进行表扫描
  尽量使用inner join查询
• 使用临时表
  如果多表连接不可避免，可以考虑使用临时表或表变量存放中间结果。
• 少用子查询
• 视图嵌套
  不要过深,一般视图嵌套不要超过2个为宜
• 少用select*

SQL优化

• NULL列
  Null列使用索引没有意义，任何包含null值的列都不会被包含在索引中。因此where语句中的is null或is not null的语句优化器是不允许使用索引的
• concat或||
  concat或||是mysql和oracle的字符串连接操作，如果对列进行该函数操作，那么也开会忽略索引的使用。比较下面的查询语句：
• like
  通配符出现在首位，无法使用索引，反之可以。当然你也可以用instr函数来替换使用。
  
• order by
  order by子句中不要使用非索引列或嵌套表达式，这样都会导致性能降低。
• Not运算
  not运算无法使用索引，可以改成其他能够使用索引的操作。如下
  
• where与having
  select … from … on … where … group by … having … order by … limit …，以上是sql语句的语法结构，其中on、where和having是有过滤行为的，过滤行为越能提前完成就越可以减少传递给下一个阶段的数据量，因此如果在having中的过滤行为能够在where中完成，则应该优先考虑where来实现。
  注：像max分组函数等，是对应的字段不能使用索引。
• exists替代in
  not in是最低效的，因为要对子查询的表进行全表扫描。可以考虑使用外链接或not exists。如下
  
• 索引
  索引的好处可以实现折半查找，时间复杂度是O(log2n)，但是也有成本，需要额外的空间存放索引数据，并且每次insert、update和delete都会对索引进行更新，因此会多增加4、5次的磁盘IO。所以给一些不必要使用索引的字段增加索引，会降低系统的性能。对于oracle来讲，SQL语句尽量大写，内部需要向将小写转成大写，再执行。
• 不要在索引列上使用函数，这样会停止使用索引，进行全表扫描，如下
• “>“与”>=”
  
• union代替or
  在索引列上，可以使用union替换or操作。索引列上的or操作会造成全表扫描
  
• is null & is not null
  如果列可空，避免使用索引。对于多个列使用的索引，起码保证至少有个列不为空。对于多列索引，只有访问了第一个列才会启用索引，如果访问后面的列则使用的是全表扫描
  
• union & union all
  union具有去重的操作，增加了计算时间。union all不需要去重，但会包含相同记录。同样功能下，首选union all操作