存储过程多表join的cost偏高源于静态执行计划与实际数据偏差：优化器按默认选择性（0.5）估算行数，导致连接方式误选；解决需启用bind-aware cursor sharing、避免函数包裹绑定变量、合理使用统计信息锁定及提示。
为什么存储过程里多表join的cost总比单独执行高？
因为存储过程编译时生成的执行计划是“静态快照”，优化器基于绑定变量的默认选择性（通常是0.5）估算cost，而实际运行时参数值可能让真实行数偏差几十倍——比如:month_code = '202605'对应千万级订单，但优化器按“平均分布”算成10万行，cost低估直接导致选错连接方式（比如该用hash join却选了nested loops）。
- 检查
DBA_HIST_SQL_PLAN里同一sql_id不同child_number的COST和E-Rows是否波动剧烈 - 对比存储过程内SQL与
EXPLAIN PLAN FOR结果：后者没绑定变量、不走游标缓存，COST参考价值低 - 确认是否启用了
bind-aware cursor sharing（查V$SQL.IS_BIND_AWARE），未启用时所有参数值共用一个计划
怎么让Oracle在存储过程中对不同参数值用不同执行计划？
核心是打破“一次编译、终身复用”，逼优化器在运行时重新评估。不是靠重写SQL，而是控制统计信息和提示的组合使用：
- 对关键参数列（如分区键、状态码）显式加
/*+ BIND_AWARE */提示，但需满足：optimizer_features_enable ≥ '11.2.0.4'且cursor_sharing = FORCE或EXACT - 避免在WHERE里对绑定变量做函数转换，例如
TO_DATE(:dt, 'YYYYMMDD')会让优化器无法利用date_col上的索引，COST估算崩盘 - 如果某张大表按月分区且数据量波动大（如
sales_202605比sales_202601大10倍），在存储过程开头调用DBMS_STATS.LOCK_TABLE_STATS('SALES')，防止夜间自动收集覆盖掉刚更新的分区统计
哪些JOIN写法会让执行计划COST虚高还难修正？
不是语法错误，而是触发优化器估算盲区，导致COST严重失真：
-
SELECT ... INTO语句里嵌套多表JOIN：Oracle按“单行预期”生成计划，实际返回千行时NESTED LOOPS的STARTS暴涨，COST模型完全失效 - 关联条件含
NVL(col, 'X') = :val：隐式转换让索引失效，且优化器对NVL输出的选择性估算极不准，COST常偏低5–10倍 - 用
UNION ALL拼接多个分支后再JOIN：各分支行数差异超10倍时，优化器放弃HASH JOIN转用NESTED LOOPS，COST陡增但PLAN_HASH_VALUE可能不变 - 嵌套视图里有
ROWNUM ，外层再关联大表：优化器误判驱动表顺序，把本该做驱动表的小结果集当被驱动方，COST虚高且<code>A-Rows远超E-Rows
验证COST是否真实反映执行开销？
别信EXPLAIN PLAN输出的COST数字，它不执行、不绑定、不读真实统计。真正要看的是最后一次真实执行的资源消耗：
- 查
V$SQL_PLAN_STATISTICS_ALL里LAST_CR_BUFFER_GETS和LAST_DISK_READS，这两个比COST更反映实际IO压力 - 运行
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('<sql_id>', NULL, 'ALLSTATS LAST'))</sql_id>，重点看STARTS和A-Rows是否与E-Rows偏差超5倍——偏差越大，COST越不可信 - 注意视图统计独立于基表：哪怕
orders表刚GATHER_TABLE_STATS过，其上定义的视图v_recent_orders的DBA_TAB_STATISTICS仍可能是陈旧的，这会直接污染COST计算
最麻烦的不是COST不准，而是这种不准藏在视图、绑定变量、统计锁定的组合里，单点调整往往无效——得同步盯住DBA_TAB_STATISTICS、V$SQL的IS_BIND_AWARE和PLAN_HASH_VALUE三个地方。
