1、这是同一个sql生成了2个执行计划
先匹配child number 0，这是一个队列
2、绑定变量无法重用所以才生成了child number 1
但是version只有2的话，应该不至于发生cursor mutex，
child number 1应该不管是从前台还是后台都跑的慢

建议：
对比下2个执行计划的区别，
查看具体绑定变量失效的原因：select * from v$sql_shared_cursor

感谢老师回复，
执行计划文本都是一样的，因为sql_id、Plan Hash Value都是一样的。
第一次生成child number 1 是硬解析没错，后面每次命中child number 1 都应该是软解析了吧？那每次child number 1 那么长的时间原因是为何?

child number 1还是硬解析，软解析的话就不会生成1了，1的运行时间长要对比执行计划~

父游标下每产生一个子游标，都对应一次硬解析。为什么1号子游标慢，比如0号游标走的索引唯一索引，1号游标走的全表扫描，自然1号游标的执行计划性能更差。具体问题需要对比两者执行计划，你可以贴图上来看看。

感谢回复
1、特意查的child number 0、child number 1 的执行计划
select * from table( dbms_xplan.display_cursor(‘sql_id’,0) );
select * from table( dbms_xplan.display_cursor(‘sql_id’,1) );
确认两个child number执行计划文本是一致的，只是 Cost (%CPU) 这里有微量差异。
那应该就如 wayne 老师所说，每次都是硬解析产生的child number 1 花费了时间，【慢在硬解析的时间上了】