绑定变量窥探本身不直接导致计划突变，但会放大统计信息偏差等影响；需通过AWR中DBA_HIST_SQLBIND与DBA_HIST_SQLSTAT关联分析peeked_bind_values和plan_hash_value的时序对应关系来确认。
绑定变量窥探（bind peeking）本身不会直接导致计划突变，但会放大统计信息偏差、直方图缺失或数据分布不均的影响；AWR能帮你确认它是否成了“导火索”，关键看同一sql_id下多个plan_hash_value是否与peeked_bind_values强相关。
怎么从AWR里确认是绑定变量窥探在作祟
不能只看执行计划变了，得锁定“同一个SQL、不同绑定值触发了完全不同的访问路径”。AWR中DBA_HIST_SQLBIND表记录了每次硬解析时被窥探到的绑定值，配合DBA_HIST_SQLSTAT的时间戳和plan_hash_value，就能对齐因果链。
- 先查该
sql_id最近7天是否真有多个plan_hash_value：运行SELECT plan_hash_value, MIN(sample_time), MAX(sample_time), COUNT(*) FROM dba_hist_sql_plan p JOIN dba_hist_sqlstat s USING (sql_id, plan_hash_value) WHERE sql_id = 'xxx' AND sample_time > SYSDATE - 7 GROUP BY plan_hash_value ORDER BY MIN(sample_time)；返回多行才值得往下挖 - 再查这些快照点对应的绑定值：用
SELECT snap_id, name, value_string, last_captured FROM dba_hist_sqlbind WHERE sql_id = 'xxx' AND snap_id IN (12345, 12346) ORDER BY snap_id, position（snap_id来自上一步结果）；重点比对value_string是否差异巨大（如'ACTIVE'vs'INACTIVE'，且后者占数据99%） - 注意
last_captured时间必须落在sample_time附近（±5分钟），否则不是同一次执行捕获的绑定值，对齐就失效
为什么DBMS_XPLAN.DISPLAY_AWR必须带+PEEKED_BINDS
不加这个格式参数，你看到的执行计划里所有谓词都是:b1这种占位符，根本没法判断优化器当时到底“看到了什么值”。而+PEEKED_BINDS会把真实窥探到的值还原进access/filter条件，让你一眼看出基数预估崩在哪。
- 执行
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('xxx', 123456789, NULL, 'BASIC +PEEKED_BINDS +NOTE'))，重点看access predicate里是否出现status = 'INACTIVE'这类字面量 - 如果某次计划用了全表扫描，而
+PEEKED_BINDS显示它窥探到了'INACTIVE'（该值在表中占比95%），但统计信息里没建直方图，那就坐实了——优化器误判选择性，以为'INACTIVE'只返回10行，实际扫了百万行 - 漏掉
+PEEKED_BINDS，你只会看到status = :b1，然后去猜、去试，浪费时间
容易被忽略的RAC和子游标陷阱
RAC环境下，不同实例可能在不同时间点对同一sql_id做了硬解析，窥探到的绑定值不同，导致各节点各自生成了不同计划——AWR默认聚合所有实例，你会看到plan_hash_value频繁跳变，但单查某个inst_id却稳定。子游标爆炸则会让DBA_HIST_SQLBIND里一堆value_string，但真正影响计划的只是其中几个“坏值”。
- 查RAC必须加
instance_number过滤：SELECT inst_id, plan_hash_value, COUNT(*) FROM gv$sql WHERE sql_id = 'xxx' GROUP BY inst_id, plan_hash_value；如果某节点独有某个plan_hash_value，优先查那个节点的dba_hist_sqlbind -
DBA_HIST_SQLBIND里可能有几十条记录，但真正触发计划切换的往往只有2–3个绑定组合；结合DBA_HIST_SQLSTAT里executions_delta突增的快照点，反向定位那几个关键snap_id即可 - 别信
v$sql当前缓存的绑定值——它只反映最后一次执行，而AWR里的last_captured才是历史证据
绑定变量窥探不是bug，是Oracle权衡解析开销和执行效率的机制；问题出在它暴露了统计信息失真、直方图缺失或应用传参不均衡。AWR给你的不是答案，而是把“哪个值、在哪个时间点、让优化器信了什么错觉”的链条钉死——这比调优hint重要得多。
