大家在大型数据库生产系统的运维中可能会遇到这样一个问题，一条查询语句，操作的是相同的表和数据，为什么在生产数据库上执行起来就很慢，而在备份数据库反而会很快。这其中一个重要原因就在于索引CLUSTER_FACTOR的不同。
Oracle数据库下，索引在做完统计分析后，会获得很多重要信息，其中之一就是CLUSTER_FACTOR，CLUSTER_FACTOR表示索引数据顺序和表数据顺序的一致性，关于CLUSTER_FACTOR的理论和机制分析见随后作者的文章，Oracle高级SQL调优之：CLUSTER_FACTOR机制研究。
CLUSTER_FACTOR的精彩之处就在于，能借此区分看来貌似完全相同的情况：表结构、表数据和索引完全相同，但就是表数据行的存储顺序不同。下面以案例的形式加以分析。
1. 研究结论
CLUSTER_FACTOR对Oracle执行计划会产生重要影响。这个值越高，说明索引的使用效率将会越差。这个值会存在于一个区间内，区间的最小值为表占用的数据块数，最大值为表拥有的数据行数。
2. 研究对象
研究对象为两个数据表TESTCF和TESTCF2，两者的数据结构相同，都只有两列：ID列，整数型，name列，字符型，80个字符，数据相同，都8万行，占用1024个数据块。不同的在于两个表的数据行的存储顺序不同，TESTCF表的数据，按照ID值从小到大的顺序依次存储，而TESTCF2表的数据，随机杂乱存储。
3. 案例实验过程
3.1 系统配置：
Oracle 11.1.0.6，初始化参数optimizer_index_cost_adj为默认值100
SQL> SELECT * FROM v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
PL/SQL Release 11.1.0.6.0 - Production
CORE 11.1.0.6.0 Production
TNS for 32-bit Windows: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 – Production
SQL> SELECT name, type, value FROM v$parameter p WHERE p.name = 'optimizer_index_cost_adj';
NAME TYPE VALUE
------------------------------ ---------- --------------------
optimizer_index_cost_adj 3 100 |
3.2 创建表TESTCF和TESTCF2
设置表TESCF控制其行长度和行数使得总共占用约1024个数据块
表定义：每行至少80个字节，共8万行，PCTFREE = 0，初始盘区和NEXT盘区都为1M
3.2.1 创建表TESTCF，并产生数据
数据的两列，分别由类序列值和随机函数产生，随机函数直接产生80位长的字符
