没有。自动索引不修改存储过程本身，也不改变pl/sql执行逻辑，仅影响其中嵌套的sql语句能否走索引访问路径；它只对高频、无索引支撑且统计信息完备的select语句可能自动创建索引并生效。
自动索引对存储过程有没有直接加速作用？
没有。自动索引不修改存储过程本身，也不改变 pl/sql 执行逻辑——它只影响其中嵌套的 sql 语句能否走索引访问路径。如果存储过程里有 select * from sales where dt = :p_date 这类查询，而 sales(dt) 没有索引，自动索引可能在几天后创建一个 ai_sales_dt 索引；但若过程里写的是 where to_char(dt, 'yyyymmdd') = :p_str，自动索引大概率不会介入，因为函数包裹列导致无法利用 b-tree 索引。
哪些存储过程场景容易触发自动索引生效？
必须同时满足以下条件，自动索引才可能“盯上”你的表和查询：
- 存储过程被反复调用（比如每天定时执行），且其中的 SQL 出现在数据库负载中频次足够高（官方未明确定义阈值，实践中通常需 ≥ 数十次/天）
- 目标表行数 ≥ 10 万，且当前无有效索引支撑该查询谓词（如缺失
WHERE status = :p_status对应的索引） - 该 SQL 在执行时已收集统计信息（
DBMS_STATS.GATHER_TABLE_STATS），否则优化器无法评估索引收益 - 执行用户具备
SELECT_CATALOG_ROLE或ADMINISTER DATABASE BUNDLE权限（部分版本要求）
注意：EXECUTE IMMEDIATE 动态 SQL 的文本若每次拼接不同（如带时间戳后缀），会被视为不同语句，难以累积“热度”触发自动索引。
启用自动索引前必须检查的三件事
别急着跑 DBMS_AUTO_INDEX.CONFIGURE，先确认基础是否就位：
- 确认当前数据库是 Oracle 19c（
SELECT * FROM v$version），且不是标准版（Standard Edition）——自动索引仅企业版支持 - 检查是否在 PDB 级别操作：自动索引配置只对当前容器生效，
ALTER SESSION SET CONTAINER = pdb_name后再执行配置 - 验证参数
_exadata_feature_on是否为TRUE：虽然非 Exadata 也能启用，但官方明确不支持问题排查；查V$PARAMETER中该隐含参数值，若为FALSE，需重启实例并加scope=spfile
常见错误是直接在 CDB$ROOT 下执行配置，结果 PDB 里完全没反应。
如何验证自动索引是否真在帮你的存储过程？
不能只看 DBA_INDEXES 里多了个 AUTO 为 YES 的索引——得确认它被实际用了：
- 查
DBA_AUTO_INDEX_EXECUTIONS，看最近是否有IMPLEMENT类型的成功记录 - 运行一次存储过程，立刻查
V$SQL找对应 SQL_ID，再用DBMS_XPLAN.DISPLAY_CURSOR(sql_id)看执行计划里是否出现新索引名（如AI_SALES_DT） - 对比开启前后同一 SQL 的
ELAPSED_TIME和BUFFER_GETS：下降 30% 以上才算有效，否则可能是统计信息偏差或并发干扰
最易忽略的一点：自动索引默认只对 SELECT 生效，DML（INSERT/UPDATE/DELETE）中的查询部分不会触发索引创建，除非这些 DML 被单独高频执行过。
