今天通过v$sql_plan、v$sqlarea等视图，定位存在Table Access Full的脚本如下：

select d.id, d.caption from t_catalog d where parentid = 77 and isvalid = 1；

首先想得的就是这个条件字段上没索引，如是马上去检测，发现在parentid上有索引，对应的创建语句如下：

create index INDEX_T_CATALOG on t_catalog(parentid);

如是，查看查询数据与总数据量的比，发现为17比179，这个比率应该走索引才是，怀疑是索引问题，删除并创建复合索引：

drop index INDEX_T_CATALOG;

create index INDEX_T_CATALOG on t_catalog(parentid,isvalid);

可发现执行计划还是按Table Access Full方式查找数据：

SELECT STATEMENT, GOAL = ALL_ROWS 耗费=3 基数=18 字节=504 CPU 耗费=96077 IO 耗费=3 操作=SELECT STATEMENT
TABLE ACCESS FULL 对象所有者=MS 对象名称=T_CATALOG 耗费=3 基数=18 字节=504 CPU 耗费=96077 IO 耗费=3 对象实例=1 操作=TABLE ACCESS

如是我就强制它走索引：

select /*+index(d,INDEX_T_CATALOG)*/ d.id, d.caption from t_catalog d where parentid = 77 and isvalid = 1

其对应的执行计划如下：

SELECT STATEMENT, GOAL = ALL_ROWS   耗费=6 基数=18 字节=504 CPU 耗费=52039 IO 耗费=6  操作=SELECT STATEMENT
TABLE ACCESS BY INDEX ROWID 对象所有者=MS 对象名称=T_CATALOG 耗费=6 基数=18 字节=504 CPU 耗费=52039 IO 耗费=6 对象实例=1 操作=TABLE ACCESS
INDEX RANGE SCAN 对象所有者=MS 对象名称=INDEX_MVS_D_CATALOG 耗费=1 基数=18  CPU 耗费=10921 IO 耗费=1  操作=INDEX

可以看出，这样强制走索引的方式，效率更差，看来Oracle决定不走索引，还是有道理的。

到了这里，是不是对这个语句，就没有办法优化了咧，考虑到这个表数据平时维护得比较少，一般都是基于该表的查询，我觉得这种情况，就适合创建bitmap index了。

drop index INDEX_T_CATALOG;
create bitmap index INDEX_T_CATALOG on t_catalog(parentid,isvalid);

去掉强制索引，再来看看这个bitmap index的效率，还是走的Table Access Full，加上强制索引，则执行计划如下：

SELECT STATEMENT, GOAL = ALL_ROWS   耗费=4 基数=18 字节=504 CPU 耗费=38047 IO 耗费=4  操作=SELECT STATEMENT
TABLE ACCESS BY INDEX ROWID 对象所有者=MVS 对象名称=MVS_D_CATALOG 耗费=4 基数=18 字节=504 CPU 耗费=38047 IO 耗费=4 对象实例=1 操作=TABLE ACCESS
BITMAP CONVERSION TO ROWIDS         操作=BITMAP CONVERSION
   BITMAP INDEX SINGLE VALUE 对象所有者=MVS 对象名称=INDEX_MVS_D_CATALOG       操作=BITMAP INDEX

效率还是不如系统默认的全表扫描了，由此可见，及时加上了索引，系统采用不采用，也可查询条件的值有关系，不同的值，对应的执行计划可能完全不一样。

ITPub博客

索引研究（一）

最新文章