自动索引不额外占用永久表空间，但会生成元数据和段，典型增长几十至几百MB；默认存于SYS用户下的默认索引表空间（如SYSTEM），索引名以SYS_AI开头，INVISIBLE索引仍占空间，UNUSABLE索引需后台任务清理。
自动索引本身不额外占用永久表空间，但会持续产生不可见/不可用索引的元数据和段，真实空间开销取决于实际创建数量与保留策略，典型生产环境单库增加几十到几百 MB，不是按 GB 级别增长。
自动索引的物理存储位置在哪
所有自动索引默认存放在 SYS 用户下，使用数据库默认的索引表空间（通常是 SYSTEM 或显式指定的 AUTO_INDEX_DEFAULT_TABLESPACE）。它不强制要求独立表空间，也不支持指定 TEMP 表空间 —— 这点常被误读。
关键事实：
-
DBA_INDEXES中自动索引名均以SYS_AI开头，visibility列为INVISIBLE或VISIBLE，status可能是UNUSABLE - 不可见索引（
INVISIBLE）仍会分配段（segment），占用数据文件空间；不可用索引（UNUSABLE）同样保留在数据字典中，直到被自动清理任务删除 - 自动索引不使用临时表空间，
TEMP暴涨和自动索引无关，那是排序、LOB 或并行操作导致的
空间增长主要来自哪几类对象
真正吃空间的不是“索引结构本身”，而是三类关联元数据和历史痕迹：
-
WRI$_ADV_OBJECTS和WRI$_ADV_RESULTS：统计信息顾问和自动索引报告共用这套底层表，尤其当AUTO_STATS_ADVISOR_TASK长期启用时，这些表可膨胀至 GB 级别 —— 但这属于统计顾问范畴，非自动索引直接产物 -
SYSAUX中的自动索引日志表（如AI$INDEX_USAGE_LOG）：记录每个自动索引被哪些 SQL 使用、是否生效等，保留窗口由AUTO_INDEX_REPORT_RETENTION控制（默认 31 天） - 已创建但尚未清理的
UNUSABLE自动索引段：它们不会立即 drop，而是等待后台任务周期性扫描后才释放；若AUTO_INDEX_RETENTION_FOR_AUTO设得过大（默认 373 天），或任务卡住，就会堆积
如何快速估算当前自动索引的空间占用
不要查 DBA_SEGMENTS 所有索引，聚焦三处：
- 查自动索引段总大小：
SELECT SUM(bytes)/1024/1024 AS mb FROM dba_segments WHERE segment_name LIKE 'SYS_AI%' AND owner = 'SYS';
- 查报告日志表空间：
SELECT segment_name, bytes/1024/1024 AS mb FROM dba_segments WHERE segment_name IN ('AI$INDEX_USAGE_LOG', 'AI$SQL_PLAN_LOG') AND owner = 'SYS'; - 确认是否混入统计顾问膨胀表：
SELECT occupant_name, space_usage_kbytes/1024 AS mb FROM v$sysaux_occupants WHERE occupant_name IN ('SM/ADVISOR', 'SM/OPTSTAT');若此处显示数百 MB 以上，大概率是AUTO_STATS_ADVISOR_TASK在作祟，而非自动索引本身
容易被忽略的关键限制与副作用
空间问题往往藏在配置盲区里：
-
AUTO_INDEX_SPACE_BUDGET默认值是50（单位 %），但它**只控制新索引创建时的预算检查，不回收已有空间**；设成 0 不会清空旧索引，只是停掉新建 - 自动索引任务（
j001进程）每 15 分钟运行一次，但清理UNUSABLE索引的逻辑是异步的，且依赖AUTO_INDEX_RETENTION_FOR_AUTO值；若该值被误设为9999，那些失败索引就永远卡在数据文件里 - 重建索引（如
ALTER INDEX ... REBUILD）对自动索引无效 —— 它们由DBMS_AUTO_INDEX管控，手动干预可能被下次任务覆盖或冲突
最常被漏掉的一点：自动索引不会为 LIKE、>、MIN/MAX 类查询建索引，所以即使开了功能，你看到的索引数量也远少于预期；空间增长慢，但排查时容易误判为“没生效”而反复调参。
