好久木有碰到 好的例子优化了，    今天遇到一个问题  绝对值得一写,  因为包括 真实执行计划， 与explan plan for ,  执行计划 差异，  是否需要使用绑定变量等

背景：   电信， oracle11g  no rac，   olap+oltp 混合特性性能。

SQL：  select * from  tabt  t where  t.id = XXXXXXX   and  t.spec_id = XXXXXX   .     3   4 分钟 不出结果

同事叫我看下  为啥这个  SQL  性能特别慢！！慢的出奇，这个F5 看其实 开销不是很小，走了索引。 我歪头 一瞅，   说这个F5 不准确，问了下 表多大， 索引多大，

果然 索引表都是很大的， 估计表20来G，  索引 2  3 G左右。   后来他又冒了一句  说  就前面这一个条件速度还蛮快的。

哈哈！！ 本来我也是一头露水，  估计答案   摸索的差不多了， 接下来应正自己的想法了，  立刻叫他把语句发来。 

于是 查看  在 v$ sql 中查出 连个SQl的SQLid，  根据SQl ID，  查询两个语句的真实执行计划，  果然两个执行计划 不一样，  原来

两个字段  都有索引，  id 选择性不错，  spec_id  选择性很不好。  （ 居然有2个索引， id  有索引合理的，  spec_id  不知道为啥有索引， 但是不给删除，吐槽下 ） 

原来走了  spec_id 的索引。一招 hint 搞定！！  2秒不到，

但是哥没有 到这里结束，  为啥语句会走不好的执行计划呢？ v$sql 中 强制把 两个值 搞成绑定变量了，共享了执行计划。 于是查询了v$pramers  这个试图，发现 Cursor_sharing的值， 强制使用绑定变量了。 还有就是 需要收集 统计信息， 直方图什么的，  

于是和电信的DBA 阐述了 为啥这个不能使用绑定变量，  表中数据严重不均衡， 当然不能使用绑定变量了。 改了这个 Cursor_sharing 的值， 

看了原来的语句，1秒！！！执行计划也正确了，此致 优化结束！！