概述

作为 Oracle 中融合全文搜索与语义搜索的核心索引类型，混合向量索引的正确使用直接影响检索性能与数据安全性。本文从实操角度出发，梳理索引创建、维护、查询的核心指南，明确当前版本的关键限制与适用场景，帮 DBA 和开发者少踩坑、高效落地。

一、索引创建核心指南（避坑第一关）

混合向量索引是整合 Oracle Text 索引与 AI 向量索引的单一域索引，任一子索引创建失败都会导致整体创建失败，因此必须同时遵守两类索引的创建规范。

1. 失败处理原则

• 若因资源不足（如 HNSW 向量索引内存池不够、表空间不足）、语法错误导致 DDL 执行失败，需手动删除无效索引后重新创建，不可直接使用。
• 若创建过程中发生破坏性操作（如 Ctrl+C 中断、数据库异常关闭），需先检查索引状态。状态非valid时，索引可能已损坏或数据不一致，必须重建。

2. 索引状态检查方法

通过 Oracle Text 内置数据字典视图查询状态，确保索引可用：

-- 查询所有混合向量索引状态（管理员视角）
SELECT idx_name, idx_status FROM CTX_INDEXES WHERE idx_type = 'HYBRID_VECTOR';

-- 查询当前用户的混合向量索引状态
SELECT idx_name, idx_status FROM CTX_USER_INDEXES WHERE idx_type = 'HYBRID_VECTOR';

状态为VALID表示可安全使用，其他状态（如FAILED、INVALID）需重建索引。

二、索引维护实操指南（性能保障关键）

混合向量索引完全兼容 Oracle Text 的维护逻辑，支持同步、优化、自动维护等操作，核心需关注默认行为与自定义配置要点。

1. 默认维护机制（无需手动干预）

• 维护模式：默认启用MAINTENANCE AUTO（自动维护），基础表执行 INSERT/UPDATE/DELETE 后，索引会在后台按最佳间隔自动同步，无需手动配置。
• 优化机制：每天本地时间午夜，自动执行 “完全优化” 作业，清理索引碎片、删除（文本索引表）、D（文档临时表）、$VR（向量索引表）中的延迟删除数据。

2. 手动维护配置（按需调整）

若默认策略不满足业务需求（如高频 DML 场景），可自定义维护规则：

• 同步配置：支持MANUAL（手动同步）、EVERY "interval-string"（定时同步）、ON COMMIT（提交后立即同步）三种模式，可通过DBMS_SCHEDULER调度后台作业。
• 建议：定期查询 Oracle Text 视图（如CTX_INDEX_PARAMETERS、CTX_USER_INDEXES），监控后台维护任务状态，避免同步 / 优化失败。

3. 针对性优化：仅优化 $VR 向量表

混合向量索引的 $VR 表存储分块与嵌入向量，高频 DML 后易产生碎片，可单独优化该表（仅压缩已删除 ROWID）：

-- 单独优化混合向量索引的$VR表（段模式，语义索引专用）
EXEC CTX_DDL.OPTIMIZE_INDEX(
    idx_name => '你的索引名',
    token_type => 'TOKEN',
    section_type => ctx_ddl.section_semantic_index, -- 指定语义索引段
    parallel_degree => 3 -- 并行度，按需调整
);

最佳实践：高频 DML（如日均万级以上插入 / 更新）场景下，建议每天手动执行 1 次 $VR 表优化，避免碎片影响查询响应速度。

三、$VR 表查询规范（数据一致性保障）

$VR 表是混合向量索引的核心二级表，存储向量分块数据，但直接查询可能导致数据不一致问题。

1. 禁止直接查询 $VR 表

索引优化作业执行前，表中可能残留已删除的行或旧数据虽然会自动过滤这些无效数据，但直接查询VR 表会获取脏数据，影响分析结果。

2. 正确查询方式：使用专用视图

Oracle 提供<index_name>$VECTORS视图，自动排除延迟删除的数据，确保查询结果准确：

-- 假设索引名为MY_HYBRID_IDX，视图名即为MY_HYBRID_IDX$VECTORS
SELECT chunk_id, vector_data, docid FROM MY_HYBRID_IDX$VECTORS WHERE docid = '目标文档ID';

该视图位于索引所属用户模式下，无需手动创建，索引创建后自动生成。

四、VPD 策略保护要求（安全合规必看）

若基础表启用了 Oracle 虚拟私有数据库（VPD）策略（用于数据访问权限控制），需同步对混合向量索引相关对象应用相同 VPD 策略，否则会出现权限漏洞：

1. 对索引关联的所有二级表（、VR、$D）应用 VPD 策略；
2. 对<index_name>$VECTORS专用视图应用 VPD 策略；
3. 确保所有针对索引的 SQL 查询、二级表直接查询（若必须执行）都遵守 VPD 策略。

详细 VPD 配置可参考《Oracle AI 数据库安全指南》，核心原则是 “基础表与索引对象权限一致”。

五、核心 DDL 限制（避坑重点！）

当前版本混合向量索引存在以下硬性限制，落地前需提前确认业务场景是否兼容：

1. 支持的列类型：仅CLOB、VARCHAR2、BLOB，不支持带 IS JSON 检查约束的文本列；
2. 向量导入限制：无法直接将外部创建的分块或向量导入 $VR 表；
3. 嵌入模型限制：仅支持数据库内 ONNX 模型，不支持第三方嵌入模型（如 OpenAI、本地自定义模型）；
4. 距离度量限制：不支持 HAMMING（汉明距离）和 JACCARD（杰卡德距离），仅支持余弦相似度等常用度量；
5. 物化视图限制：不能基于VECTOR_CHUNKS、UTL_TO_CHUNKS、UTL_TO_EMBEDDING等函数的输出创建物化视图；
6. DML 跟踪：向量索引部分（IVF/HNSW）的 DML 跟踪行为与纯向量索引一致，无额外扩展。

六、适用场景与选型建议

结合上述限制，Oracle 官方推荐以下场景优先使用混合向量索引：

1. 需在文本文档（CLOB/VARCHAR2/BLOB/JSON 类型）中执行混合搜索（关键词 + 语义）；
2. 需灵活切换纯关键词、纯向量、混合搜索模式的场景（如法律文档分析、医学文献检索）。

不建议使用的场景：

1. 数据仅需语义搜索，无需关键词匹配；
2. 需使用第三方 REST API 生成向量嵌入（如调用 Oracle 私有 AI 容器、OpenAI 接口）—— 此类场景建议直接使用纯向量索引。

总结

混合向量索引的核心优势是 “一站式整合双重检索能力”，但落地时需重点关注三点：创建失败必须重建、高频 DML 后需优化 $VR 表、严格遵守数据类型与模型限制。若业务场景涉及混合搜索且无第三方向量嵌入需求，它是最优选择；若存在限制中的冲突点，建议优先考虑纯 Oracle Text 索引或纯向量索引。

如果需要针对具体业务场景（如高频更新场景的维护脚本、VPD 策略配置示例）生成实操代码，或想了解某类限制的规避方案，欢迎在评论区留言交流！