23c默认禁用自动索引（auto_index_mode=off），且启用后采用延迟物理构建，首次访问才生成index段，故dba_segments中长期不可见；19c则默认启用并立即分配段。
Oracle 19c 和 23c 的自动索引行为差异显著，不能直接对比“段变化”——因为 23c 默认禁用自动索引（AUTO_INDEX_MODE = OFF），而 19c 是唯一默认启用并实际落地该功能的 LTS 版本。
为什么查不到 23c 的自动索引段？
23c（即 23ai）虽保留 DBMS_AUTO_INDEX 包和相关视图，但启动逻辑已重构：
-
AUTO_INDEX_MODE参数默认值为OFF，且官方文档明确要求“必须显式设为IMPLEMENT才启用”，不像 19c 那样默认ON后自动建索引 - 即使设为
IMPLEMENT，23c 的自动索引也绕过传统段分配路径，改用轻量元数据标记 + 延迟物理构建（首次访问时才生成INDEX段），所以DBA_SEGMENTS中长期看不到对应段 -
DBA_AUTO_INDEX_EXECUTIONS视图在 23c 中返回空或仅记录“评估未执行”，而非真实建索引动作
19c 中自动索引段生成的真实路径
在 19c 中，只要 AUTO_INDEX_MODE = ON 且满足阈值（如 SQL 执行次数 ≥ 5、响应时间 ≥ 1s），系统会在后台作业中完成完整段创建：
- 索引段名固定以
SYS_AI_开头，出现在DBA_SEGMENTS.SEGMENT_NAME中，类型为INDEX - 对应索引对象可在
DBA_INDEXES查到，GENERATED列为YES，AUTO列为YES - 段空间立即分配（哪怕空索引），可通过
SELECT bytes FROM dba_segments WHERE segment_name LIKE 'SYS_AI_%'直接验证
对比操作必须绕过“自动”二字
真要横向看段行为，得关掉自动机制，统一用人工触发方式观察：
- 在 19c 中执行：
EXEC DBMS_AUTO_INDEX.CONFIGURE('AUTO_INDEX_MODE','OFF');，再手动运行DBMS_AUTO_INDEX.REPORT_ACTIVITY获取建议，最后用CREATE INDEX显式建索引——此时段行为与传统索引完全一致 - 在 23c 中同样先设
AUTO_INDEX_MODE = OFF，然后调用DBMS_AUTO_INDEX.REPORT_LAST_ACTIVITY提取推荐语句，再手工执行CREATE INDEX - 两者段生成结果无区别：都走标准 DDL 流程，段名由用户指定或系统生成（如
ISEQ$$_...），DBA_SEGMENTS立即可见，SEGMENT_TYPE为INDEX
容易被忽略的兼容性断层
23c 的自动索引不是 19c 的升级版，而是重写版；它把“是否建索引”的决策权从数据库内核上收到了 AI 引擎层。这意味着：
- 19c 的
DBA_AUTO_INDEX_IND_OBJECTS视图在 23c 中字段含义已变，IMPLEMENTED列不再表示“段已存在”，而是“AI 已批准该索引逻辑” - 23c 中
DBA_INDEXES的AUTO列可能为YES，但STATUS是UNUSABLE—— 因为物理段尚未生成，这点和 19c 的“建完即可用”完全不同 - 迁移脚本若依赖
SYS_AI_段名做清理（如DROP INDEX SYS_AI_...），在 23c 上会报ORA-01418：不存在该索引
