最近看到一个系统的负载比较高，引起了我的注意，查看AWR报告发现，竟然是因为两条很简单的SQL语句导致。     语句有多简单呢，就是下面的两个SQL语句。

select companyname from license

select supdepid from hrmdepartment where id =''

    突然发现以前也发现了这个问题，但是最后也是不了了之，还是因为单纯从数据库的层面调整要灵活快捷的多，从业务层面来推动还是有一定的难度和阻力。之前的分析： http://blog.itpub.net/23718752/viewspace-2062157/

   表License的数据只有1行，表hrmdepartment对的数据有2000多行，id是主键，含有非空约束。     为什么这么小数量的表，含有主键，怎么还会导致严重的性能问题呢。 看执行计划第一个语句是全表扫描，里面只有1行记录，全表和索引扫描应该差别很小。      就是这样一个语句，在一个小时的时间里竟然执行了近2000多万次。 这样一条SQL的影响被无限放大，就导致了数据库的负载很高。 如此来看，每秒钟的执行频率极高，1秒钟差不多是6000多次的频率。什么系统有如此之高的业务需求。 和开发的同学交涉，原以为分析已经到位，剩下的就是快刀斩乱麻似的解决问题了。但是发现问题比我想象的要糟糕很多。 目前的情况是，大家都认为这是一个问题，但是让人很无奈的情况是这个系统是一个外部系统，目前还没有源码，所以也就意味着这是一个黑盒的环境了。 我看了下出问题的用户的结构信息，真让我大跌眼镜，大量的存储过程和触发器，表竟然有1万多个，我倒吸一口冷气，这个问题的情况确实比我想的难，准确的说是糟糕。  sh findobj.sh USERV6|grep TABLE|wc -l 11904 $ sh findobj.sh USERV6|grep TRIGG|wc -l 1580 $ sh findobj.sh USERV6|grep INDEX|wc -l 1542 $ sh findobj.sh USERV6|grep PROC|wc -l 2149 换句话说，从应用层面来调整SQL的可能性极小。碰到这种情况真是无语了。但是抱怨和牢骚解决不了问题。我一边和开发的同学沟通，一边想数据库层面能不能做点什么。 select companyname from license这样一个语句，不能动SQL还有什么优化空间了。目前来看有一个改进之处是索引，表里有10多个字段，输出只有一个字段，表里存在一行记录。所以也就尽可能提高访问的效率，10%的改进被无限放大也是一个很理想的值。     而且如果SQL语句能够修改的情况下，我有什么好的办法来改进，这都是我需要考虑的问题。 我用一个新的用户来做了一番测试。 create table license tablespace users as select * from  USERV6.LICENSE ; exec dbms_stats.gather_table_stats(ownname=>null,tabname=>'LICENSE'); 可以看到执行计划是走了全表扫描 SQL> set autot trace exp stat 尝试1： 因为这个表只存在1行记录，而且从表结构信息来看数据是唯一的，于是我尝试创建一个唯一性索引。 create unique index index_lic_companyname on license(companyname); 重新收集统计信息 SQL> exec dbms_stats.gather_table_stats(ownname=>null,tabname=>'LICENSE'); 再次查看，发现CBO还是走了全表扫描。执行计划没有发生改变。 尝试2： 尝试添加hint,设置cardinality都是一样的结果，没有任何改变。 select /*+index( license index_lic_companyname)*/ companyname from license select /*+cardinality( license,1)*/ companyname from license 尝试3： 我想到了一个新的改进方法，就是sample,可以根据随机算法得到数据。但是尝试结果依旧没有任何变化 select companyname from license sample(1); 尝试4： 尝试rownum的形式，结果依旧。 SQL> select companyname from license where rownum<=1; 尝试5： 启用cache选项，把数据牢牢放入cache里面，减少被换出的概率，但是在这个极端场景下，还是没有任何的改进。 SQL> alter table license cache; 尝试6： 如果我启用了Unique Index的时候，即SQL语句改为下面的形式，结果不言而喻，肯定是非常理想了。 select companyname from license where companyname='xxxx' 但是改动成为上面的情况的可能性我几乎为0，想想挺美好，总是有巨大的差距。 尝试7： 既然在这个特殊场景中，我们需要查询的是companyname这个字段，有什么办法把索引和表结合起来呢。一种方式就是IOT,即索引组织表了。 重新创建表   CREATE TABLE "CYDBA"."LICENSE_IOT"    (    "COMPANYNAME" VARCHAR2(100) primary key,         ...         "DOCUMENT" CHAR(1)    ) organization index   TABLESPACE "USERS" ; 插入1行数据。 SQL> insert into LICENSE_IOT select * from license; 1 row created. SQL> commit; 收集统计信息。 SQL>exec dbms_stats.gather_table_stats(ownname=>null,tabname=>'LICENSE_IOT'); 可以看到还是有了不小的改进。 这个结果让我还是充满信息，准备近期部署上去对比一下，希望看到鲜明的差距。第2条SQL继续优化，还是一块不好啃的骨头。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-2127027/，如需转载，请注明出处，否则将追究法律责任。