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

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

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

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

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

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

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

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

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

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

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

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