-------------------------------------
select count(*) from t where id=:"SYS_B_0"
Plan hash value: 2966233522
---------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 15 (100)| |
| 1 | SORT AGGREGATE | | 1 | 2 | | |
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
|* 2 | TABLE ACCESS FULL| T | 20081 | 40162 | 15 (0)| 00:00:01 |
---------------------------------------------------------------------------
执行计划为全表扫描，生成了一个新的执行计划。
由此我们可以得到结论：
当cursor_sharing设置为SIMILAR的时候，Oracle对没有使用绑定变量的SQL字面语句都会进行处理，将where条件后自动替换为绑定变量；在执行语句是，对每一个条件设置值，都会生成一个新的child cursor子游标，与父游标相对应。当一个语句输入的时候，如果之前存在过相同条件值的SQL子游标，就共享该子游标。否则生成一个新的child cursor，生成一个匹配的执行计划；SIMILAR是FORCE的进化版。在SIMILAR模式下，Oracle对游标共享的条件变得比较敏感。如果绑定变量值发生变化，就意味着执行计划可能存在不匹配的情况。所以索性Oracle对每一个新的值都bind peeking一下，生成执行计划。而执行计划游标的共享只在相同绑定变量的时候才发生。这个与FORCE相比，cursor_sharing=SIMILAR的确缓解了由于bind peeking单次带来的执行计划不匹配问题。但是会引入两个新问题：如果对应条件列的取值相对较少，这样生成执行计划的个数起码是可以控制的。如 果是一种连续取值情况或者对应取值很多，必然引起parent cursor对应的child cursor数目增多，每次从child cursor列中遍历的时间增加，latch和pin发生的时间增多。这也是similar取值是一个常见的问题；生成child cursor的标准不是是否执行计划相同，而是绑定变量值相同。这样如果数据分布较为平均，所有值对应的执行计划都是相同的。那么生成很多的子游标执行计划必然是相同的。这样又会带来性能和其他一些问题。 在谓词条件的列后没有直方图时，其作用和force类似，会共享子游标（可以删除where条件后列上的直方图重复最后一步实验验证）Cursor_sharing设置为similar，存在一些BUG，即使是force也同样有BUG存在。例如导致EXPDP的导出时间变成，物化视图的更新变慢等。Oracle 并不建议你设置此参数。在12C中ORACLE将废除similar的设置。