如果有人问你，假设表t的col1字段上已经创建了索引，那么
Select * from t where t.col1=‘123‘
这样的SQL会走索引还是全表扫描，你会怎么回答？
答案是不确定。因为字段t.col1的值选择度不同的时候，执行计划是不一样的。我们简单做个实验验证一下：
Create table t as select * from dba_objects;
Create index idx1 on t (object_id);
Select count(object_id) from t;
Exec dbms_stats.gather_table_stats(user,‘T‘,cascade=>True);
Explain plan for select * from t where t.object_id=123; --此时选择度为1/1317175
此时的执行计划
Select * from table(dbms_xplan.display());
现在我们把1/4的记录都设置成OBJECT_ID=123。
Update t set object_id=123 where mod(object_id,4)=1;
Commit;
Select count(object_id) from t where t.object_id=123;
Exec dbms_stats.gather_table_stats(user,‘T‘,cascade=>True);
Explain plan for select * from t where t.object_id=123; --此时选择度近1/4 (329629/1317175)
此时的执行计划
Select * from table(dbms_xplan.display());
此时的cardinality = 316K ，这个值是如何得到的呢？
查询T.OBJECTID列直方图信息：
可知该列上收集了直方图信息，直方图类型为等高直方图，桶数为254。
继续查看该直方图的详细信息：
Endpoint_number从61开如,可知1-60号桶的endpoint_value也是123。即object_id=123的记录共占用了61个桶,而桶的总个数为254,因此object_id=123的选择度为61/254，进而得到cardinality=1317175 * (61/254) / 1000 = 316 。
下一篇，我们分析一下oracle spatial 空间查询条件（例如对一个矩形范围作sdo_filter操作）对执行计划的影响。