1 直方图定义
在oracle数据库中，CBO会默认认为数据在最小值和最大值之间是均匀分布的，并且会按照均匀分布原则计算目标列查询条件的可选择率，计算成本选择执行计划，但是目标列的数据是均匀分布这个原则并不是正确的。
在实际的系统中，我们很容易看到一些目标列的数据分布是不均匀的，甚至极度偏斜、分布极度不均衡，对这样的列如果按照均匀分布原则去计算可选择率与cardinality，并根据此计算成本，那么CBO所选择的执行计划可能是不合理的，甚至是错误的。
一个例子，由于数据极度不平衡，而且未收集直方图导致的错误执行计划
SQL> update t1 set object_id=1;
72770 rows updated.
SQL> commit;
Commit complete.
SQL> update t1 set object_id=2 where rownum<10;
9 rows updated.
SQL> commit;
Commit complete.
SQL> select object_id,count(1) from t1 group by object_Id;
OBJECT_ID COUNT(1)
---------- ----------
1 72761
2 9
SQL> select table_name,histogram from dba_tab_col_statistics where table_name='T1' and column_name='OBJECT_ID';
TABLE_NAME HISTOGRAM
-------------------- --------------------
T1 NONE
SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS('SYS','T1',ESTIMATE_PERCENT=>100,METHOD_OPT=>'FOR ALL COLUMNS SIZE 1');
SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS('SYS','T1',ESTIMATE_PERCENT=>100,METHOD_OPT=>'FOR COLUMNS SIZE AUTO OBJECT_ID' ,CASCADE=>TRUE);
SQL> set lines 120
SQL> col table_name for a20
SQL> col HISTOGRAM for a20
SQL> select table_name,histogram from dba_tab_col_statistics where table_name='T1' and column_name='OBJECT_ID';
TABLE_NAME HISTOGRAM
-------------------- --------------------
T1 FREQUENCY
收集直方图方案
FOR ALL [INDEXED|HIDDEN] COLUMNS [SIZE 1-255 \AUTO]
FOR COLUMNS SIZE AUTO DEPTNO,NAME
FOR COLUMNS EMPNO SIZE 10 NAME SIZE 5
FOR COLUMNS EMPNO SIZE 1
2 直方图与绑定变量
变量窥探一般情况下在select语句使用绑定变量都会去窥探，与字段上有无索引、直方图信息无关，虽然个人认为在没有直方图和索引的情况下意义不大，但是oracle都会去窥探变量值然后根据变量值生成执行计划，可以修改隐含参数"_optim_peek_user_binds"为FALSE禁用变量窥探（可能会引起性能问题），不过11g中引入自适应游标共享后这个问题得到了改善，在10g中直方图和变量窥探是相互矛盾的，为了性能的稳定性，需要人为去做好控制，不收集直方图信息或者不使用绑定变量，当然具体的方案都需要根据具体的情况进行分析测试。
最后需要注意的是默认情况下只收集在where条件中使用过的字段的直方图，视图sys.col_usage$中记录是否使用过不做任何查询或者DML收集统计信息：
我们知道当我们拥有了histograms的统计信息之后我们就可以使用这些信息计算我们的选择率和基数。但是如果我们使用了绑定变量的时候，情况总会有所改变。
首先，在Oracle9i里面新引入了bind variable peeking的功能，这个功能我们前面讲过，是一个带绑定变量的SQL第一次parse的时候，让CBO可以根据绑定的具体的值来决定所要使用的执行计划，而以后如果遇到同样的SQL，即使绑定变量的值不一样，也不会在peek绑定变量的值，而是使用已经生成的计划。这里的一个潜在的问题就是如果我们有了histograms信息，而且我们的数据分布是一小部分数据的分布和其他部分的分布相差很远，那么当我们在做bind variable peeking，如果很不幸运的peek到了那一小部分的数据，就会导致以后所有的同样的SQL都使用了不恰当的执行计划。
当然这个bind variable peeking有时候也有意外，那就是如果我们存在shared pool里的执行计划信息或其他相关的信息由于某种原因失效了或者被age out of shared pool，那当我们再次运行这个SQL的时候，就会重新peek绑定变量的值，从而重新生成计划。关于执行计划信息或其他相关的信息的失效或age out，可以通过v$sql的reloads和invalidations字段获得。
和绑定变量有关的另一个就是参数cursor_sharing，cursor_sharing这个参数有三个取值：FORCE、EXACT、SIMILAR。
有时候，很可能是在OLTP的系统中，为了最大限度的减少SQL PARSE的消耗，让类似的SQL可以尽可能的重用，我们会考虑设置cursor_sharing为force。当cursor_sharing被设置为force的时候，优化器会用系统指定的绑定变量来替代SQL里面所有的literal constants，然后以此为基础判断我们的shared pool里面是不是有可以重用的cursor。按照我们上面的讨论，设置cursor_sharing为force对histograms影响最大的，因为系统指定的绑定变量替换后很可能与histograms收集的数据分布不符。
这个问题可以有两个解决办法,一是在我们认为影响会很到的SQL里面加上hint /*+ cursor_sharing_exact */，这回告诉CBO对于这个SQL采用cursor_sharing=exact的策略。另一个解决方法是设置cursor_sharing=similar，按照Oracle文档的说法，设置cursor_sharing为similar也会首先把SQL里的literals替换为绑定变量，并且也会在第一次分析SQL的时候做bind variable peeking，但是当以后重新运行类似的SQL的时候，CBO会查看如果发现新的绑定变量会影响到执行计划（当然，之所以会产生不同的执行计划往往是因为存在histograms），就会重新生成执行计划。经过一些实验，我们可以发现，当设置cursor_sharing=similar的时候，如果我们的条件是range scan或等于的条件，并且条件涉及的列上有histograms信息的时候，CBO会在分析SQL的时候对绑定变量做检查，如果发现新的绑定变量有可能影响SQL的执行计划，则会重新评估并生成新的计划。
但是往往我们在优化系统的一个方面的时候会导致其他方面的问题，cursor_sharing=similar就是一个很典型的例子，当我们这样的设置的时候，首先优化器的压力会变大，因为CBO要做很多的重新优化。更严重的问题在于cursor_sharing=similar会导致同样的SQL（除了绑定变量的值不一样之外）在library cache里面拥有很多不同的执行计划，因为我们知道一个SQL下面的所有执行计划都是被一个latch保护的，所以cursor_sharing=similar会导致更严重的latch 争用。因此当我们使用cursor_sharing=similar的时候，除非必要，无需统计histograms信息，因为我们要保证我们为了解决一个问题不会导致其他的更严重的问题。