存储过程关联查询走错执行计划是因为编译时固化计划，而运行时参数变化、数据偏移、统计过期等导致原计划失效；需用bind_aware提示、避免绑定变量函数转换、锁定统计、绑定sql profile等动态优化。
为什么存储过程里的关联查询总走错执行计划？
因为存储过程编译时生成的执行计划会固化，而运行时参数值变化、数据分布偏移、统计信息过期等因素会让原计划不再适用。尤其当关联多张大表、嵌套视图或使用动态拼接条件时，explain plan看到的“理想路径”和实际跑出来的v$sql_plan经常不一致。
怎么让存储过程用上正确的执行计划？
核心是打破“一次编译、长期复用”的陷阱，让优化器在关键节点重新评估：
- 对高频变动参数的查询，显式加
/*+ BIND_AWARE */提示（需 11gR2+ 且optimizer_features_enable≥ 11.2.0.4） - 避免在
WHERE子句里对绑定变量做函数转换，比如TO_CHAR(:dt, 'YYYYMMDD')会直接让索引失效 - 若关联逻辑固定但数据量波动大（如按月分区表），在存储过程开头调用
DBMS_STATS.LOCK_TABLE_STATS锁定关键统计，防止夜间自动收集干扰 - 用
DBMS_SQLTUNE.LOAD_SQLSET把典型执行场景捕获进 SQL Tuning Set，再用DBMS_SQLTUNE.ACCEPT_SQL_PROFILE绑定稳定计划
大表关联时哪些写法会让执行计划崩掉？
不是语法错，而是触发了优化器的估算盲区：
- 在存储过程中用
SELECT ... INTO查询多行结果——Oracle 会按单行预期生成计划，遇到实际返回千行就卡住 - 嵌套视图里含
ROWNUM 或 <code>FETCH FIRST N ROWS ONLY，外层再关联大表，优化器常误判驱动表顺序 - 关联条件里混用
NULL安全比较（NVL(col, 'X') = :val），导致无法走索引，且COST估算严重偏低 - 用
UNION ALL拼接多个分支查询后整体再关联，优化器可能放弃哈希连接转而用嵌套循环，尤其当各分支行数差异超 10 倍时
验证执行计划是否真被用了？
别只信 EXPLAIN PLAN FOR，它不执行、不绑定变量、不走真实游标缓存：
- 在存储过程里加
DBMS_OUTPUT.PUT_LINE(DBMS_UTILITY.FORMAT_CALL_STACK)定位具体 SQL 行号，再查V$SQL_PLAN中对应sql_id和child_number - 用
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'ALLSTATS LAST'))查最后一次真实执行的统计，重点关注STARTS（实际启动次数）和A-Rows（实际返回行数）是否与预估E-Rows偏差超 5 倍 - 如果发现
NESTED LOOPS的STARTS是 100 万次，但驱动表只有 100 行，说明优化器把小表当成了被驱动方——立刻检查关联字段是否有隐式类型转换
最易被忽略的是：存储过程里调用的视图，其统计信息独立于基表。哪怕基表刚 GATHER_TABLE_STATS 过，视图的 DBA_TAB_STATISTICS 仍可能是陈旧的。别跳过 DBMS_STATS.GATHER_SCHEMA_STATS 的 options => 'GATHER AUTO' 参数，它会连带刷新依赖视图的统计快照。
