虚拟列必须显式创建索引并收集统计信息、定义须为确定性函数，且查询条件须精确匹配索引列，三者缺一都无法触发INDEX RANGE SCAN。
虚拟列上没建索引，自然不走
Oracle 虚拟列本身不存储数据，只在查询时按定义表达式实时计算。哪怕你在分区键里用了虚拟列（比如 TO_CHAR(order_date, 'YYYYMM')），只要没在该虚拟列上显式创建索引，优化器就无法利用它加速 WHERE 条件匹配。
常见错误是以为“用了虚拟列分区 = 自动有索引”，其实分区策略和索引是两回事。虚拟列要支持高效查询，必须单独建索引：
- 如果查询条件直接写
order_month = '202510'，且order_month是虚拟列，就得有CREATE INDEX idx_order_month ON t(order_month) - 如果查询仍用原始列（如
order_date >= DATE '2025-10-01'），那原始列上的索引才有效，虚拟列索引完全无关 - 注意：虚拟列索引必须是「函数索引」的等价形态，但语法更干净——不需要重复写表达式，直接索引虚拟列名即可
分区裁剪（Partition Pruning）生效 ≠ 索引命中
很多人看到执行计划里写了 PARTITION RANGE SINGLE 就以为“走索引了”，其实这只是说明 Oracle 成功跳过了无关分区，底层访问方式仍是全表扫描（TABLE ACCESS FULL）或索引全扫描（INDEX FULL SCAN），未必是高效的索引范围扫描（INDEX RANGE SCAN）。
关键要看执行计划第二行（Access Predicates）是否包含索引字段 + 范围/等值条件：
- ✅ 有
access("ORDER_MONTH"='202510')且索引存在 → 真正命中索引 - ❌ 只有
filter("ORDER_MONTH"='202510')→ 先读整个分区再过滤，虚拟列未被索引化 - ⚠️ 分区键和查询条件类型不一致（比如虚拟列是
VARCHAR2，但传入数字参数）会触发隐式转换，直接让虚拟列索引失效
统计信息缺失或过期，优化器不敢用
虚拟列不像物理列那样自动收集统计信息。即使你建了索引、也写了正确条件，若没手动为虚拟列收集统计信息，优化器会因“不知道数据分布”而低估索引效率，倾向选择全表扫描。
必须显式执行：
EXEC DBMS_STATS.GATHER_TABLE_STATS( ownname => 'SCHEMA_NAME', tabname => 'T', method_opt => 'FOR ALL COLUMNS SIZE AUTO FOR COLUMNS SIZE AUTO order_month' );
其中 order_month 是你的虚拟列名。漏掉这步，DBA_TAB_COL_STATISTICS 里查不到它的 NUM_DISTINCT 和 HISTOGRAM，优化器就当它“全是一样的值”，索引成本算出来比全表还高。
虚拟列定义含不确定函数，索引被禁用
Oracle 对虚拟列索引有严格限制：定义中不能含非确定性（non-deterministic）函数，否则建索引会报错 ORA-54017，或者建成功但运行时拒绝使用。
典型踩坑点：
-
SYS_GUID()、SYSDATE、USER、UID—— 这些函数每次调用结果不同，虚拟列值不固定 -
TO_CHAR(date_col, 'DD')没问题，但TO_CHAR(date_col, 'DAY')在不同 NLS 设置下返回值可能变（如英文 vs 中文环境），也可能被判定为不可索引 - 自定义 PL/SQL 函数未声明
DETERMINISTIC—— 即使逻辑确定，没加这个关键字，Oracle 也不认
检查方法：SELECT column_name, data_type, virtual_column, hidden_column FROM dba_tab_cols WHERE table_name = 'T' AND virtual_column = 'YES'; 再结合 dba_ind_columns 确认索引是否真落在该列上。
最常被忽略的是：虚拟列索引不是“建完就灵”，它依赖统计信息 + 确定性定义 + 查询条件与索引列完全对齐。三者缺一，执行计划里那个绿色的 INDEX RANGE SCAN 就永远出不来。
