在Oracle 19c中，函数索引本身不能可靠加速表达式JOIN，必须配合显式定义的虚拟列+函数索引，并确保JOIN条件两端表达式对称（如ON c.name_upper = u.name_upper），否则优化器因无法归一化推导而放弃索引、退化为全表扫描。
直接回答：在Oracle 19c中，用函数索引本身就能加速表达式JOIN，但若想让JOIN条件中的复杂表达式（如 UPPER(a.name) = UPPER(b.name)）真正走索引，必须配合虚拟列 + 函数索引，且JOIN字段两端需保持表达式对称——否则优化器大概率放弃索引，退化为全表扫描。
为什么函数索引在JOIN里经常失效？
Oracle对JOIN谓词的索引选择非常保守。即使你在 a.name 上建了 UPPER(name) 函数索引，当写成 UPPER(a.name) = b.name 时，优化器无法保证 b.name 值域与索引键完全对齐，会拒绝使用该索引。
- 常见错误现象：
EXPLAIN PLAN显示走全表扫描，Cardinality估算严重偏低，Cost却异常高 - 根本原因：CBO要求JOIN两侧表达式结构可“归一化”；单侧函数调用破坏了等价性推导
- 真实场景：用户表和客户主数据表做姓名模糊匹配，但两边都存大小混排的姓名
必须创建虚拟列并显式引用它
不能只依赖函数索引自动隐式生成的 SYS_NC00xxx$ 列——那列是只读、不可见、无法在SQL中直接写入JOIN条件的。你得自己定义一个命名清晰、类型明确的虚拟列，并在JOIN中显式使用它。
- 操作步骤：
ALTER TABLE customers ADD (name_upper AS (UPPER(name)) VIRTUAL); ALTER TABLE users ADD (name_upper AS (UPPER(full_name)) VIRTUAL); CREATE INDEX idx_cust_name_upper ON customers(name_upper); CREATE INDEX idx_user_name_upper ON users(name_upper);
- 关键点：
VIRTUAL表示不占物理存储，但可被索引和查询；类型由表达式自动推导，建议显式指定（如VARCHAR2(100)）避免隐式转换 - JOIN必须写成：
ON c.name_upper = u.name_upper，而不是ON UPPER(c.name) = UPPER(u.full_name)
注意统计信息和执行计划验证
虚拟列默认不收集统计信息，CBO会按“未知分布”估算基数，极易导致错误的连接顺序（比如把大表当驱动表）。
- 必须手动收集：
DBMS_STATS.GATHER_TABLE_STATS要加参数method_opt => 'FOR ALL HIDDEN COLUMNS SIZE AUTO' - 验证是否生效：
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY) WHERE plan_table_output LIKE '%INDEX%';确认出现INDEX RANGE SCAN或INDEX UNIQUE SCAN - 性能陷阱：如果
name_upper值重复率极高（如大量“NULL”或空格），索引选择性差，仍可能被CBO跳过——此时应加WHERE name_upper IS NOT NULL过滤
最易被忽略的是：虚拟列名一旦写进生产SQL，就成为接口契约的一部分。后续若改表达式（比如从 UPPER 改成 TRIM(UPPER())），所有依赖它的JOIN逻辑都会出错，且错误不会在编译时报出，而是在运行时数据不一致——这点比普通索引严格得多。
