1. 为什么说 26ai 不是一次常规版本升级
最近不少搞数据架构的朋友都在翻 Oracle 26ai 的资料，我手里这套用 35 张架构图讲 Oracle AI Database 26ai 技术架构的图册，也被不少人传过。老实说，我第一次看到版本号从 23ai 跳到 26ai 时，第一反应是大概又在云上加了几个 AI 功能，给自治数据库补点新特性，然后再换一个名字。等我把 35 张图一张张过完，才意识到这代产品改的不只是功能清单，而是数据库本身的定位。
26ai 这个名字可以拆成两段理解：26 对应产品发布的时间节奏，延续云数据库每年一个大版本的做法；ai 则是明确告诉你，这一代把 AI 当作数据库的一等公民来设计。注意，这里说的不是"数据库旁边加一个 AI 服务"，而是把 AI 相关的数据形态、计算方式、推理流程直接塞进数据库内核。说直白一点，以前做智能应用，普遍是"数据库存数据，外面再用 Python、向量库、模型服务拼一条流水线"。26ai 想做的事，是让数据库自己理解向量、自己执行推理调用、自己管理模型生命周期，甚至让优化器在规划 SQL 执行计划时，把"是否走向量索引"也当成一个普通的成本选项。
这篇文章是上篇，核心任务只有一个：带大家按图纸顺序把前 20 张图逐组过一遍。我之所以坚持按图序讲，是因为整套架构图分了几个层次：先看全局定位与部署形态，再看存储与查询内核，最后才是 AI 平台与自治运维。前 20 张把数据库这个底座讲透，后面的模型接入、安全策略和多云扩展，放到下篇单独展开更合适。
你可以把这篇文章当成一份"看图笔记"。我不会把 35 张图的内容全部复述一遍，而是挑每张图里真正影响架构决策的细节，把背后的为什么讲清楚。适合正在做数据库选型、准备把业务改造成 AI 原生应用、或者单纯想理解现代数据库往哪里走的读者。哪怕你暂时没有用 Oracle 的计划，里面关于向量检索、融合查询、模型推理进数据库这些设计，对其他数据库产品也有很强的参照价值。
2. 35 张图的正确打开方式：先抓住看图顺序
2.1 先分清三组视角，再开始逐张看图
架构图最怕一上来就盯着某一张细节猛看，结果被存储结构图上的小方块搞晕。我拿到这套图册后，先做了一件事：把图号写在便签上，按内容分组。整套 35 张图大致可以分成三组视角：
- 第 1~5 张是全局视角：讲产品定位、版本能力总览、部署形态，以及"数据库+AI"放在一起后的整体分层。
- 第 6~16 张是内核视角：围绕存储、内存、查询引擎、优化器展开，这一组是上篇的重点。
- 第 17~35 张是平台视角：模型接入、推理路径、自治运维、安全与多云扩展。
前两组的思路很清晰：先回答"数据库自己有什么变化"，再回答"AI 能力以什么姿态进来"。如果跳过存储和查询直接看模型接入，你会误以为 26ai 只是给数据库套了一个模型网关，那就把最核心的部分漏掉了。
2.2 上篇图注速查表：前 20 张图到底在讲什么
我把上篇要讲的前 20 张图整理成了一张速查表，方便你对照着看：
| 图号 | 核心内容 | 看图时重点关注 |
|---|---|---|
| 1~2 | 产品定位与版本能力总览 | 26ai 强调"AI 原生数据库"，而不是 AI 增强 |
| 3~5 | 部署形态与整体分层 | 云、本地、混合架构下的组件边界 |
| 6~7 | 持久化存储与数据文件布局 | AI 数据类型如何与行存、列存共存 |
| 8~10 | 内存与列式存储、向量索引 | 向量索引的构建与更新路径 |
| 11~13 | 融合查询引擎 | SQL、全文、向量、图查询如何统一 |
| 14~16 | 优化器与执行引擎 | 向量相似度搜索怎么进成本模型 |
| 17~18 | 模型接入与推理路径 | 模型注册、推理调用在数据库内部如何流转 |
| 19~20 | 自治运维与 AI 诊断 | 系统如何用 AI 做故障预测和参数调优 |
表格是个索引，不是结论。后面每一节，我会把其中真正的设计关键拆开说。
2.3 看图时最容易踩的坑：把逻辑架构当成物理拓扑
看架构图有个常见误解：以为图上的每个方框都对应一台服务器或一个进程。实际上这套图里的绝大部分是逻辑组件，比如查询引擎、向量索引、模型推理服务，它们可能运行在同一个数据库进程组里，也可能分布在多个实例上，具体取决于部署形态。你要是把逻辑架构当成物理拓扑，就会问出"融合查询引擎是不是单独部署了一个集群"这种问题，然后自己把自己绕晕。
还有一个坑是忽略图的边界。很多图只画了 26ai 自己内部的东西，模型服务可能来自外部大模型 API，也可能来自你自建的推理服务。图上往往用一条虚线表示"外部依赖"，有人没注意虚线边界，以为数据库把私有化大模型也包进去了，后面谈成本和安全的时候就会产生误判。
3. 从存储与计算底座看起：03-10 张图背后的设计逻辑
3.1 AI 数据类型不是简单的"新增一种字段"
图 6 到图 7 展示的是存储层的变化。过去的 Oracle 数据库有 NUMBER、VARCHAR2、CLOB、JSON 这些数据类型，到了 23ai 引入了 VECTOR 类型，26ai 在存储层把 VECTOR 相关的布局做得更系统化了。VECTOR 字段在逻辑上就是一个数组，但物理存储要考虑的问题比想象中多：是行存还是列存？向量要压缩吗？相似度计算时要读满整个向量还是可以做裁剪？
图 6 里画的数据文件布局，我理解核心思路是：向量的原始值和向量派生出的索引结构分开存放。原始值跟着主表走，索引结构放进专门的索引段。这样做的直接好处是，事务提交、回滚、备份恢复这些传统机制不需要为向量做颠覆性改造，向量数据可以沿用数据库成熟的一致性保障。你不需要自己在应用层维护"向量表"和"业务表"的一致性，这在以前用外部向量数据库时是个大麻烦。
3.2 内存列式存储与向量索引的配合
图 8 到图 10 连续三张，实际上在讲同一个性能故事：查询时数据从哪里来、索引怎么加速。
In-Memory 列式存储已经不是新东西，但在 AI 场景下它多了一个很重要的用途——批量向量相似度计算。行存适合点查询和事务处理，但在"从 1000 万条记录里找出跟某条向量最相似的前 10 条"这种场景里，行存的访问效率不如列存。列存把一列的数据紧凑地放在连续内存里，CPU 可以顺序扫描，再配合 SIMD 指令做距离计算，吞吐量会好看很多。
向量索引则是另一个加速手段。图 10 里给出了两条路径：精确搜索走暴力扫描，近似搜索走索引。注意这里的设计取舍：数据库没有强制你"必须建索引才能用向量搜索"。对小数据量，全表扫描配合列存完全够用；数据量上来了，可以选择 HNSW 这类近似索引。这个"可选性"很重要，因为它意味着你不需要为了测试一个 Demo 就去建索引、调参数，可以先用最简单的方式跑通业务，再根据规模逐步上索引。
3.3 为什么把向量索引进内核，而不是旁边挂一个插件
这是我在读图过程中觉得最值得展开的设计决策。市面上不少数据库选择把向量检索做成"外部组件 + 回调"的方式，比如通过 FDW 或者自定义函数去调用独立向量库。26ai 图里的做法是让向量索引变成数据库的"普通索引类型"。这意味着什么？
代价和计划是统一建模的。优化器知道有向量索引存在，它可以根据数据分布、查询条件、WHERE 过滤强度，决定是直接走向量索引，还是先用过滤条件缩小范围再算相似度，还是干脆全表扫。不是每个查询都适合走向量索引，比如你有 1000 万条数据但过滤条件能先把范围缩小到 100 条，那直接算相似度可能更快。只有把向量索引放进优化器的成本模型里，才能自动化地做这种判断。
一致性也是统一管理的。向量索引随事务更新，随备份备份，随恢复恢复。你在外部向量库里写入了数据，往往还要写一套同步任务，遇到数据不一致半天排查不出来。放进内核之后，这套复杂度被数据库吸收了，对应用开发者来说是实打实的减负。
4. 融合查询引擎：11-16 张图里最值钱的设计
4.1 SQL、向量、全文、图查询，凭什么能揉在一起
图 11 到图 13 展示的融合查询引擎，是整个上篇里我最想让大家认真看的部分。传统认知里，SQL 擅长结构化数据，全文检索归搜索引擎管，向量相似度是向量库的活，图查询又属于图数据库。把这些揉到一个查询引擎里，难点不只是"都能用"，而是"在一个 SQL 里能用"。
图上传递的信息是：融合查询引擎以 SQL 为统一入口，把不同类型的算子都实现成 SQL 表达能力的一部分。比如在 SELECT 子句里调用 VECTOR_DISTANCE 函数算相似度，在 WHERE 里加一个全文 CONTAINS 条件，在 ORDER BY 里同时按相似度和业务属性做排序。这听起来像语法糖，但背后要实现的是统一的类型系统和执行计划。
举个例子，一个很典型的 RAG 场景：用户要查"性能好且评价接近某个描述的产品"。传统做法是把结构化过滤（价格、库存）、全文检索（评价文本）、向量检索（描述语义）分开调用三个系统，再在应用层做过滤、拼接、排序，最后还得自己处理各个系统返回结果集的页码问题。融合查询引擎要做的，是让这一整条链路在数据库内部完成，应用只需要提交一条 SQL，拿回一个结果集。
4.2 混合搜索不是简单的"取交集"
图 12 里专门有一块讲混合搜索（Hybrid Search）。我见过不少人对混合搜索的理解是：把向量搜索结果和全文搜索结果做一个交集。真实情况复杂得多。语义搜索可能返回 A 结果，关键词搜索返回 B 结果，两者的相关性置信度不在一个量纲，你怎么合并排序？
图上画了一条融合排序的路径：先把各路的候选集都捞出来，然后用一个可配置的权重公式做 RRF（Reciprocal Rank Fusion）或者加权得分融合，最后统一排序。这个细节说明产品团队很清楚混合检索的难点不在召回，而在融合排序。权重怎么调、阈值怎么设，都需要业务实测，不是 SQL 写出来就能拿到好效果。
4.3 优化器如何估算向量相似度成本
图 14 到图 16 是优化器和执行引擎的内容。数据库优化器最擅长的是估算行数和代价，但"向量距离计算"的代价模型与传统谓词完全不同。假设一个查询要算每个候选向量和目标向量的余弦相似度，然后再取 top 10，优化器需要估算的是：候选集多大？每条向量的维度多高？走 HNSW 索引的 IO 成本是多少？如果同时有文本过滤条件，过滤率大概是多少？
图上这几个参数我理解分别对应：数据分布统计（直方图扩展）、向量维度信息、索引类型选择、过滤谓词的成本权重。真正实现的时候一定比图上画的复杂，但这个方向是对的——把 AI 查询当成一类普通查询来优化，而不是当成特殊通道。这样维护成本更低，也更容易预测性能。
5. AI 平台层与自治运维：17-20 张图在講什么
5.1 模型推理服务怎么进入数据库
看到第 17、18 张图，才进入真正的 AI 平台部分。图上展示的模型接入方式，不是简单地在数据库里内置一个开源模型，而是提供了一个模型抽象层。模型可以来自三处：数据库内置的小模型、你注册进来的开源模型（通过 ONNX 等格式）、以及远程大模型 API。对 SQL 开发者来说，它们统一表现为一个函数调用。
这个设计解决了一个很实际的问题：你的业务不需要被模型供应商绑架。你可以先用远程大模型 API 跑通应用，等业务量上来、或者数据安全要求变严之后，把模型替换成本地推理服务，SQL 层的调用方式不用推倒重来。反过来也一样，本地小模型效果不理想，可以切回远程大模型。
数据不落地的推理路径是图 18 的重点。当你在一条 SQL 里调用 AI 函数处理某一行数据时，数据流经内存、进入模型推理、返回结果，整个过程不需要把数据导出到数据库外部。对数据管控严格的环境来说，这是相比"数据库+外部 AI 服务"方案最根本的优势。
5.2 自治数据库的能力在 AI 时代有了新内涵
图 19 到图 20 开始进入自治运维的部分。老版本里的自治数据库，重点在自动备份、自动打补丁、自动调优。26ai 的图里，自治能力多了一条关键链路：用 AI 诊断数据库自身的运行状态。
图上有一个很有意思的闭环：数据库运行时采集指标和日志，AI 服务分析异常模式，如果是参数问题就自动调整，如果是容量问题就建议扩容，如果是 SQL 性能问题就生成索引建议。这个闭环和外部监控工具的本质区别在于，25 系版本就能自动做不少诊断，但 26ai 强调把诊断经验直接沉淀在数据库代码里，而不是靠外部运维人员读取告警再决策。
5.3 资源隔离与 AI 工作负载治理
AI 查询和传统 OLTP 跑在同一个数据库里，最大的隐患是资源争抢：一个向量搜索批量任务可能把 CPU 吃满，导致线上交易变慢。图 20 旁边的小图讲的正是这个问题的解法，通过资源管辖区（Resource Manager）把 AI 工作负载放进独立配额池。
我在实际调优时最怕的也是这类问题。AI 场景经常有跑批式的向量化任务，比如每晚把新增文档全部过一遍 embedding，这类任务和交易查询并发，没有隔离就是事故现场。架构图上把 AI 工作负载单独画成一个池子，说明设计上已经默认这种隔离是基线能力，而不是事后补丁。
6. 看图时容易忽略的细节：安全模型与应用改造
6.1 推理数据不落盘，不等于没有日志审计
第 17、18 张图虽然讲了推理路径不经过外部服务，但别忽略数据库本身是有完整审计体系的。AI 函数调用一样会产生 SQL 执行记录、访问日志、以及数据变更记录。你在图上看到"数据不出域"，应该联想到的是"能审计、能追溯、能限权"。对应用开发者来说，这意味着 AI 功能的权限管理使用数据库原有体系控制即可，不需要额外建一套授权系统。
我在实际项目里看到过因为"AI 调用算不算数据访问"没定义清楚导致的安全漏洞：业务方以为推理服务只是传一句文本过去，不会留存输入，结果外部模型服务商在日志里存了所有 prompt。26ai 这种以内置推理为核心的路径，至少在权限和审计上能跟现有数据库体系对齐，少很多扯皮。
6.2 AI 工作负载的存储与算力成本要算两笔账
看图和实际做方案之间差着一本成本账。向量存储本身要占用空间，向量索引要占用内存，模型推理需要 CPU 或 GPU 资源。图 8 到图 10 只画了性能路径，没有画资源配额。你自己规划容量时，要把这几项单独列出来：
- 原始向量数据：维度 × 行数 × 每个分量的字节数，再算上压缩率。
- 向量索引：HNSW 的图结构通常比原始向量占空间更大，图里的参数会显著影响内存。图 8~10 里没有直接展示索引内存占用，但你要清楚这是大头。
- 推理资源：本地模型推理和远程 API 的成本模型完全不同。本地模型要预留 CPU/GPU，远程 API 则是按调用量付费，两者都需要纳入架构决策。
6.3 应用的改造路径：不需要一步到位
很多人看到新版本有向量索引、有 AI 函数，就准备推翻原有架构重写。架构图册里没有明说，但这个产品定位已经暗示了一条渐进式路径：你完全可以先把一个检索模块从外部向量库迁移到数据库里，其他部分不动；跑稳之后再逐步把全文搜索、图关系查询并进来。同时，SQL 作为统一入口也意味着，行为变化对应用是局部性的，不用把整个数据访问层换掉。
拿我参与过的一个知识库项目举例。最初架构是关系库里存文档元数据、外部向量库存切分后的向量，业务侧同时查两个库，再在服务端合并结果，延迟高而且经常出现两边数据不一致。后来把向量字段加进主表，把原本外部向量库的写入逻辑全部去掉，应用代码改动集中在 DAO 层，查询耗时反而降了。现在看到 26ai 这组图，我会更倾向于让这种融合发生在数据库内部而不是应用层拼装。
7. 上篇读图笔记之外：留给下篇的问题和自己的看图习惯
这套架构图我读了两遍，上篇对应的前 20 张图讲到这里，最大的感受是：数据库厂商终于不把 AI 当外挂功能了，而是把它当成数据库原生的能力矩阵来做。但正因为能力铺得很开，真正落到项目里时，问题也会更立体：模型怎么选型、推理性能怎么压测、多模型之间的排序权重怎么调、多云部署下数据如何同步，这些都需要拿具体业务数据来验证。架构图给出的是边界和路径，不是答案。
我自己的看图习惯是：第一步先给整套图做分组索引，第二步逐个组件追问"它解决什么问题、为什么需要存在、边界在哪"，第三步再倒回去看全局图，确认组件之间怎么协作。这套方法比按顺序从头读到尾更容易形成体系化理解。
下篇再接着拆后十几张图，重点是模型接入的完整链路、安全策略、多云与本地化部署的差异，以及 AI 工作负载的资源管理细节。如果你正在评估把 AI 能力放进数据库内部这条路，上篇提到的融合查询、向量索引、推理数据不出域这三个点，值得先在实际场景里做个最小验证。
