Oracle数据库版本命名从23c变为23ai，这一变化并非简单的字母替换，而是明确传递出产品战略重心的转移。过去十年，Oracle数据库主推多租户、内存列式存储和自动管理，如今则将AI能力直接下沉到数据库内核，让开发者无需在应用层与数据库之间频繁搬运数据就能完成向量检索、语义匹配等智能操作。这种设计思路对AI应用的架构简化、性能提升和安全性都有直接影响。
AI向量搜索：让SQL直接处理语义相似度
在传统AI应用架构中，文本嵌入向量通常存储在独立的向量数据库里，比如Pinecone或Milvus，而业务数据则存放在关系型数据库中。开发者必须维护两套系统，处理数据同步、权限控制等一系列复杂问题。Oracle 23ai直接引入了原生向量数据类型VECTOR，可以将嵌入向量作为普通列存储在表中，并针对该列创建专门的向量索引。这样一来， AI应用可以直接使用标准SQL进行相似度搜索，不再需要外挂组件。
向量搜索的核心在于距离计算。Oracle提供了VECTOR_DISTANCE函数，支持欧几里得距离、余弦相似度、点积等多种度量方式。下面的示例展示了如何创建包含向量列的表，插入数据并执行相似度查询。
-- 创建具有向量列的商品表
CREATE TABLE products (
id NUMBER PRIMARY KEY,
name VARCHAR2(200),
description_embedding VECTOR(768, FLOAT64)
);
-- 插入向量数据（假设已经通过外部模型生成嵌入）
INSERT INTO products VALUES (
1,
'无线蓝牙耳机',
'[0.023, -0.112, 0.894, ...]' -- 实际为768维向量
);
-- 查询与给定向量最相似的前5个商品
SELECT id, name
FROM products
ORDER BY VECTOR_DISTANCE(
description_embedding,
:query_vector,
COSINE
)
FETCH FIRST 5 ROWS ONLY;
为了加速大规模向量检索，Oracle提供了两类向量索引：IVF（倒排文件）和HNSW（分层可导航小世界图）。IVF索引适合数据量较大且允许近似结果的情况，它先对向量空间进行聚类，查询时只搜索最相关的几个簇，从而大幅减少计算量。HNSW索引则基于图结构，通常能提供更高的召回率和更低的延迟，但构建和存储开销更大。开发者可以根据数据规模和精度要求灵活选择。
从架构角度看，向量搜索下沉到数据库带来了三个明显好处。第一，数据安全策略可以统一管理，向量数据不再散落在外部系统中。第二，减少了网络传输和序列化开销，尤其在高并发场景下性能提升显著。第三，事务一致性得到保障，业务数据和向量数据可以在同一个事务中更新，避免了跨系统的一致性问题。
JSON关系二元性：一份数据，两种视图
现代应用开发普遍使用JSON作为数据交换格式，而数据库内部通常使用关系表存储数据。这种差异导致开发者需要编写大量的对象关系映射代码，不仅增加了复杂度，还容易引入性能陷阱。Oracle 23ai引入的JSON关系二元性（JSON Relational Duality）提供了一种优雅的解决方案：允许在关系表之上创建JSON文档视图，应用程序可以像操作JSON文档一样读写数据，而底层数据仍然以规范化的关系表形式存储。
创建二元性视图的语法类似于创建普通视图，但需要指定文档的结构和引用的基础表。下面的示例展示了基于部门表和员工表创建一个包含嵌套员工信息的部门JSON文档视图。
-- 创建基础关系表
CREATE TABLE departments (
dept_id NUMBER PRIMARY KEY,
dept_name VARCHAR2(100)
);
CREATE TABLE employees (
emp_id NUMBER PRIMARY KEY,
emp_name VARCHAR2(100),
dept_id NUMBER REFERENCES departments(dept_id),
salary NUMBER
);
-- 创建JSON关系二元性视图
CREATE JSON DUALITY VIEW dept_docs AS
SELECT JSON {
'deptId' : d.dept_id,
'deptName' : d.dept_name,
'employees' : [
SELECT JSON {
'empId' : e.emp_id,
'empName' : e.emp_name,
'salary' : e.salary
}
FROM employees e WITH UPDATE
WHERE e.dept_id = d.dept_id
]
}
FROM departments d WITH UPDATE;
通过这个二元性视图，应用既可以使用简单的SQL插入一行部门记录，也可以使用JSON文档一次性插入一个包含多个员工的部门。数据库会自动处理底层关系表的拆分和维护，保证引用完整性。例如，使用以下语句即可通过JSON文档更新部门信息：
UPDATE dept_docs d
SET d.data = '{"deptId":10,"deptName":"研发部","employees":[
{"empId":101,"empName":"张三","salary":25000},
{"empId":102,"empName":"李四","salary":28000}
]}'
WHERE d.data.deptId = 10;
这种设计消除了关系模型和文档模型之间的根本矛盾。数据库管理员仍然可以依赖成熟的关系表设计、约束和索引来保证数据完整性，而开发人员则可以使用自然的JSON操作来减少样板代码。更重要的是，二元性视图支持完整的ACID事务，无论通过哪种视图修改数据，一致性都由数据库引擎统一保证。
SQL和开发者体验的实质性提升
除了AI和JSON这两大亮点，Oracle 23ai还引入了一批旨在简化SQL编写和提高执行效率的特性。其中SQL宏（SQL Macro）尤为值得关注。传统上，开发者经常需要在多个查询中重复编写类似的表达式或子查询，而视图和存储过程又无法完全替代所有场景。SQL宏允许开发者定义可重用的、参数化的SQL片段，这些片段在查询编译时被内联展开，既减少了代码重复，又不会产生额外的运行时开销。
下面的示例定义了一个SQL宏，用于计算员工的年薪（月薪乘以12），然后在查询中直接使用该宏。
-- 创建SQL宏函数
CREATE OR REPLACE FUNCTION annual_salary(monthly_salary NUMBER)
RETURN VARCHAR2 SQL_MACRO(SCALAR) IS
BEGIN
RETURN q'{
monthly_salary * 12
}';
END;
/
-- 在查询中使用SQL宏
SELECT emp_name, annual_salary(salary) AS yearly_salary
FROM employees;
SQL宏不仅限于标量表达式，还可以用于表宏（Table Macro），将一段复杂的多表连接逻辑封装成可复用的单元。这对于数据仓库中的复杂报表查询特别有用。值得注意的是，SQL宏在编译时展开，因此不会引入类似存储过程调用的上下文切换开销，执行计划可以与直接编写SQL完全一致。
另一个值得关注的安全增强是SQL防火墙（SQL Firewall）。它能够学习应用程序的正常SQL模式，并自动阻止异常的SQL语句执行，从而防范SQL注入攻击和内部数据滥用。例如，如果某个应用通常只执行特定结构的SELECT语句，突然出现一条包含UNION的语句，防火墙会拦截并发出告警。该特性在数据库内核层面增加了纵深防御能力，尤其适合对安全要求严格的金融和医疗行业。
性能方面，True Cache提供了一个内存中的一致性缓存层，可以自动保持与主数据库的事务一致性。应用可以将读请求路由到True Cache节点，减轻主库压力，同时避免传统缓存中常见的数据不一致问题。这项功能对于读多写少的互联网应用非常实用。
总体来看，Oracle 23ai的新特性紧密围绕AI时代的开发需求，将向量搜索、JSON灵活性和SQL开发效率提升融为一体。无论是构建智能推荐系统、重构传统关系型应用，还是加固数据库安全防线，这一版本都提供了切实可行的内核级支持，而无需额外引入复杂的外部组件。
Oracle数据库23aiAI向量搜索JSON关系二元性修改时间：2026-09-22 13:33:21