存储过程中的静态sql不会自动进入v$sql，必须实际执行才会生成游标；动态sql（execute immediate）则在执行时才入v$sql。查执行计划需准确定位sql_id，用display_cursor时参数顺序和类型须严格匹配，且statistics_level需设为all。
存储过程里的sql不会自动进v$sql，得手动触发执行
存储过程编译时不会执行内部sql，所以哪怕你刚调用完存储过程，v$sql里也大概率查不到对应语句——除非该sql被单独硬解析过，或者过程里用了动态sql（execute immediate或dbms_sql）。静态sql在过程体中只是“待命状态”，只有真正运行到那条语句时，才会生成游标并进入库缓存。
实操建议：
- 确保存储过程已成功执行一次（不是只
EXEC了但中途异常退出） - 避免在过程里用
PRAGMA AUTONOMOUS_TRANSACTION包裹目标SQL——它会切到独立事务和会话上下文，导致执行计划归属分离 - 如果过程含条件分支（比如
IF ... THEN ... ELSE），确认你执行的路径确实走到了目标SQL那一支
查不到sql_id？先从v$sqlarea或v$sql找线索
直接用DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'ALLSTATS LAST')往往失败，因为“最后执行的SQL”大概率是CALL或EXEC语句本身，不是过程体内的SQL。必须主动定位目标SQL的sql_id。
常用查找方式：
- 执行完存储过程后，立刻查
v$sqlarea，按last_active_time倒序，过滤sql_text含关键表名或字段名：SELECT sql_id, child_number, sql_text FROM v$sqlarea WHERE sql_text LIKE '%your_table%' AND last_active_time > SYSDATE - 1/1440 - 若过程内SQL带绑定变量，
sql_text显示的是带:B1等占位符的版本，别指望看到明文值 - 查
v$sql比v$sqlarea更细粒度（含child_number），但需加address和hash_value联合判断重复
DISPLAY_CURSOR参数填错会导致返回空或报ORA-01002
DBMS_XPLAN.DISPLAY_CURSOR三个参数顺序和含义容易混淆：第一个是sql_id（字符串），第二个是cursor_child_no（数字或NULL），第三个是format（字符串）。填错任意一个，结果可能为空、报错或返回无关计划。
典型错误：
- 把
child_number当sql_id传——DBMS_XPLAN.DISPLAY_CURSOR(123, NULL, 'TYPICAL')→ ORA-01002 -
sql_id拼写错误或大小写不匹配（Oracle里sql_id是大小写敏感的） - 没设
STATISTICS_LEVEL=ALL就用'ALLSTATS LAST'→ A-Rows、Buffers等列全为null - 用
NULL代替0表示子游标号，但实际有多个子游标时，NULL会返回全部，可能混入旧版本计划
动态SQL（EXECUTE IMMEDIATE）要单独处理
存储过程里用EXECUTE IMMEDIATE 'SELECT ...'的SQL，其执行计划独立于过程本身，且sql_id生成规则与普通SQL一致——但它在v$sql里出现的时间点是EXECUTE IMMEDIATE执行那一刻，不是过程编译或调用时刻。
关键操作：
- 确保
EXECUTE IMMEDIATE语句执行成功（无异常中断） - 在
EXECUTE IMMEDIATE之后立刻查v$sql，延迟哪怕几秒都可能被其他SQL挤出缓存 - 如果SQL文本含换行或多余空格，
v$sql.sql_text里也会保留，LIKE匹配时得带上%兜底 - 对动态SQL加注释（如
/*+ MONITOR */）可提升其在v$sql_monitor中的可见性，但不影响DISPLAY_CURSOR调用
真实执行计划的“真实”二字，本质是依赖SQL真正在库缓存中留下带统计信息的游标。存储过程这层封装，让这个前提变得隐蔽——你得亲手把它拽出来，而不是等它自动浮现。
