存储索引是oracle exadata专有特性，仅在exadata硬件（x2-2及以上）、11.2.0.2+版本、启用smart scan且表存于exadata asm磁盘组时生效；非exadata环境完全不支持，也无法通过create index创建。
存储索引 是 oracle exadata 专有特性，oracle 11g 标准版、企业版（非exadata硬件）完全不支持存储索引。它不是 sql 层可配置的索引对象，也不是 dba 能通过 create index 创建或管理的东西。
如果你在非 Exadata 环境下查 V$SQL_PLAN 或执行计划里看到 “storage index” 字样，那基本是误读——实际看到的可能是 INDEX RANGE SCAN 或 STORAGE 相关的提示（如 STORAGE(…) hint），但绝非真正的存储索引。
为什么你查不到 storage index 的效果？
因为它的存在前提非常硬性：
- 必须运行在 Oracle Exadata 数据库云服务器（X2-2 及之后所有代际）上
- 数据库版本需为 11.2.0.2+，且启用智能扫描（Smart Scan）——即查询走的是 cell server，不是 database server
- 表必须存放在 ASM 磁盘组中，且该磁盘组由 Exadata storage cells 管理
- 查询需满足 Smart Scan 触发条件：全表扫描或快速全索引扫描 + 过滤条件能下推到 storage layer
换句话说：没 Exadata 硬件，storage index 就是零字节的幻影。
如何确认当前环境是否真有 storage index 在工作？
只看两个地方，缺一不可：
- 查
V$SQL中对应 SQL 的IO_CELL_OFFLOAD_ELIGIBLE_BYTES和IO_INTERCONNECT_BYTES：前者远大于后者，说明有 offload - 查
V$CELL_METRICS或CELLSRV日志，找storageIndexHit/storageIndexMiss计数器（普通 DBA 通常无权限；需 celladmin）
别信 EXPLAIN PLAN 输出里的“Storage Index”字样——那是旧版文档或错误渲染。真实执行计划中不会出现该访问路径名称，它属于 storage layer 内部优化，对 SQL 引擎透明。
替代方案：11g 普通环境想加速表空间级扫描，只能靠这些
既然没有 storage index，就得回归传统但有效的手段：
- 确保统计信息最新：
EXEC DBMS_STATS.GATHER_TABLE_STATS('SCOTT', 'EMPLOYEES')，否则 CBO 可能误判成本，放弃可用索引 - 用分区裁剪（Partition Pruning）：按时间/区域建范围分区，让
WHERE sale_date >= DATE '2026-01-01'自动跳过无关分区 - 用覆盖索引避免回表：
CREATE INDEX idx_sales_cover ON sales(sale_date, amount, product_id) INVISIBLE，把 SELECT 列全包进去 - 对大表全扫场景，考虑并行：
SELECT /*+ PARALLEL(t, 4) */ * FROM sales t WHERE ...，但注意并发资源争用
最后提醒一个容易被忽略的点：即使你在 Exadata 上，storage index 也只对列存格式（如 HCC 压缩表）和特定过滤模式（等值、IN、BETWEEN）有效；对 LIKE '%abc'、函数索引字段、LOB 列等一律无效——它不是万能加速器，而是带严格边界的硬件协同机制。
