公众号：杨建荣的学习笔记 · 作者：杨建荣 · 发布：2016-10-27 23:41:04 · 原文链接

继续前几天的一次性能调优，这次调优难度不小，而且空间很小，看起来简直就是绝处逢生的感觉。下面的两条SQL语句执行频率极高，每秒达到6000次，希望能够优化。
select companyname from license

select supdepid from hrmdepartment where id=”
前几天分析了一下，也尝试了很多种方法，但是始终无法启用索引，最后采用IOT的形式才看到效果，这是其一。可以参见每秒执行6000的简单SQL优化（一）（r10笔记第62天）
还有一点很多明眼人看出来了，为什么创建了唯一性索引，表license中存在1行记录，但是却无法启用，一个根本原因就是唯一性索引的列没有非空约束。
为此我又进行了一次测试，添加了主键，那么就会是非空约束和唯一性主键。

create table license tablespace users as select * from  USERV6.LICENSE ;
alter table license modify(companyname primary key);
exec dbms_stats.gather_table_stats(ownname=>null,tabname=>'LICENSE');测试结果如下：

可以看到达到了预期的改进效果。但是改进幅度到底有多大呢。
我们抓取了一个awr的报告来看看。
改进前，是全表扫描，每次执行的buffer gets是7

而改进之后的情况如下:

第一条语句的优化暂且到这里，如果是在11g中，可能result cache还有有一些改进之处。
再来看看第二条语句。
select supdepid from hrmdepartment where id=”
表hrmdepartment这种id是主键列，但是查询使用了id=”
查看执行计划可以很明显看到Filter的处理，里面的条件很微妙NULL IS NOT NULL

这样一个语句怎么优化呢，一个很明显的处理方式就是在SQL中做检查，尽可能调整逻辑。
但是让人尴尬的是这个应用是闭源的，无法直接修改里面的逻辑。怎么改进，或者说有什么是DBA能想办法缓解的。
首先使用唯一性索引是最高效的索引扫描方式。

能够沾沾索引的光，其实还真有点门路，那就是创建一个复合索引，基于列(supdepid,id)