在传统数据库的世界里，SQL是一门"门槛语言"。

这个门槛有多高?我见过做了五年数据分析的人，LEFT JOIN和INNER JOIN还分不清楚。也见过业务部门为了拿一个简单的月度统计，发邮件、等排期、反复沟通，一来一回耗掉三天。而DBA这边呢?每天被各种"帮我跑个数"的需求塞满，正经的调优工作全得加班干。

这个困局持续了很多年。BI工具试图解决，但BI需要建模，建模需要理解数据，最终还是绕不开技术人员。低代码平台试图解决，但低代码平台本身也是个新系统要维护。

直到我试了Oracle 26ai里的Select AI。

说"试用"其实不太准确。最开始是领导让我评估一下Oracle 26ai的新特性到底能不能落地。我翻了一圈文档，300多项新特性，看得眼花。直到看到"Select AI"这个功能——用自然语言查数据库。

我的第一反应是：又是一个演示版的花架子吧?类似的东西我不是没试过，早些年有些NL2SQL的实验项目，问"上个月卖了多少"能猜对，问"上个月华北区退货率TOP3的品类分别是谁"就开始胡说八道了。

但这次不一样。认真读了一遍文档之后，我在测试环境配了一套，让业务部的老王上去试了试。不到十分钟，他自己查出了五六条以前得找我才能跑的数据。他惊叹的那一刻，我就知道这东西是真的能用的。

这篇文章就是来聊聊Select AI到底能干什么、怎么配置、实际效果如何、有哪些坑要避。不是官方文档的翻译版，是摸着石头过河的真实体验。

## Select AI到底是个什么逻辑

先简单说清楚Select AI是什么，免得后面看晕了。

Select AI是Oracle AI Database 26ai内置的一个功能。它的核心能力就一句话：**你用自然语言问问题，它自动生成SQL，帮你在数据库里查，再把结果用自然语言告诉你**。

你不需要会写SQL。你只需要说人话。

比如你问"去年每个季度的销售总额是多少"，Select AI会在后台把这句话转成一条带GROUP BY的SQL，跑完之后返回一个表格或者一句自然语言的总结。

这个东西不是靠规则匹配——它背后连着一个大语言模型(LLM)，可以是OCI的模型、OpenAI、Azure OpenAI、Google Gemini、Anthropic Claude，甚至还支持Hugging Face上自己部署的开源模型。你用哪个模型，就在配置里选哪个。

LLM负责理解自然语言、生成SQL、解释结果。Oracle数据库负责执行SQL、返回数据。两者通过一个叫AI Profile的配置连接起来。

说白了，Select AI = 数据库 + LLM + 一条自然语言输入通道。

这个组合的好处是，LLM的强项(理解含糊的自然语言)和数据库的强项(精准地执行查询)互补了。LLM不需要自己"猜"数据——它把自然语言翻译成SQL，数据库执行SQL拿到真实数据，LLM再基于真实数据回答用户。比起那些完全靠LLM内部知识回答问题的方案，这个架构天然就能避免幻觉。

我在测试环境里跑了几百条问题，涵盖销售查询、客户分析、库存统计，准确率大概在85%-90%之间。剩下10%-15%有偏差的问题，大部分是问法太模糊导致的。

## 从0到1配置一套Select AI

说了这么多，不如直接上手配一套。我拿自己在测试环境里搭的过程当例子，一步步来。

### 第一步：准备一个LLM的访问凭据

Select AI需要连一个LLM才能工作。我用的是OpenAI的接口，因为手头正好有额度。

先创建一个凭据对象，把API key存进去：

```sql

BEGIN

DBMS_CLOUD.CREATE_CREDENTIAL(

credential_name => 'OPENAI_CRED',

username => 'OPENAI',

password => 'sk-your-api-key-here'

);

END;

/

```

如果用的是OCI自己的模型，凭据参数会不一样——要填user_ocid、tenancy_ocid、private_key这些。但形式是一样的，都是通过 `DBMS_CLOUD.CREATE_CREDENTIAL` 创建。

然后要配网络访问控制。Oracle数据库默认不会允许自己往外部的API发请求，得明确授权：

```sql

BEGIN

DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(

host => 'api.openai.com',

ace => xs$ace_type(

privilege_list => xs$name_list('http'),

principal_name => 'ADB_USER',

principal_type => xs_acl.ptype_db

)

);

END;

/

```

这里的 `ADB_USER` 是实际要用Select AI的数据库用户名。如果之后换了其他LLM提供商，把host改成对应的API地址就行。

### 第二步：创建AI Profile

AI Profile是整个Select AI的配置中心。它告诉数据库：用哪个LLM、查哪些表、要不要开对话记忆、用不用向量索引等等。

```sql

BEGIN

DBMS_CLOUD_AI.CREATE_PROFILE(

profile_name => 'SALES_ANALYST',

attributes => '{

"provider": "openai",

"credential_name": "OPENAI_CRED",

"model": "gpt-4o",

"object_list": [

{"owner": "SH", "name": "customers"},

{"owner": "SH", "name": "sales"},

{"owner": "SH", "name": "products"},

{"owner": "SH", "name": "countries"}

],

"comments": true,

"conversation": true,

"enforce_object_list": true

}'

);

END;

/

```

这里几个关键属性说明一下：

-`provider`: 指定AI提供商。我用的openai，也可以用oci、azure、google、anthropic等。

-`credential_name`: 上一步创建的凭据名称。

-`model`: 具体模型名。OpenAI不指定的话默认是gpt-3.5-turbo，我换成了gpt-4o，效果更好。

-`object_list`: 限定了LLM能查询哪些表和视图。这是安全边界——不在列表里的表，Select AI不会去碰。我把SH schema下的几张销售相关的表加进来了。

-`comments`: 设成true的话，LLM会读取表和列的注释来理解字段含义。这对SQL生成的准确性帮助很大。所以建表的时候字段注释写得好不好，直接影响Select AI的效果。

-`conversation`: 开启对话记忆。这样问完"上个月销售额"之后，可以接着问"环比增长多少"，LLM能记住上个月指的是什么。

-`enforce_object_list`: 强制只查列表内的对象，防止LLM"自由发挥"去访问权限内的其他表。

### 第三步：授权用户

让业务用户能用Select AI，需要给他们执行权限：

```sql

GRANTEXECUTEON DBMS_CLOUD_AI TO BUSINESS_USER;

```

如果要用RAG(检索增强生成)功能，还需要：

```sql

GRANTEXECUTEON DBMS_CLOUD_PIPELINE TO BUSINESS_USER;

```

### 第四步：开始查询

配置完了。切换到业务用户的会话，激活Profile：

```sql

EXEC DBMS_CLOUD_AI.SET_PROFILE('SALES_ANALYST');

```

然后就可以问问题了：

```sql

SELECT AI how many customers do we have;

SELECT AI showsql what were the total sales lastquarter;

SELECT AI explainsql which product category had the highest profit margin;

```

就这么简单。

`SELECT AI` 是关键词，后面跟自然语言，支持好几种"动作"(action)：

-`runsql`(默认)：生成SQL并执行，返回结果

-`showsql`：只显示生成的SQL，不执行——适合想学SQL的人

-`explainsql`：用自然语言解释生成的SQL在做什么

-`narrate`：对查询结果做自然语言的描述

-`chat`：把问题直接发给LLM，不走数据库查询

-`showprompt`：显示完整发送给LLM的提示词

我最常用的是 `runsql` 和 `showsql`。

## 实战演示：一个业务场景

为了让效果更直观，我在SH schema下模拟了一个电商销售的场景。

包含四张表：`customers`(客户)、`products`(产品)、`sales`(销售记录)、`countries`(国家地区)。数据量不大，几百条测试数据，但覆盖了常见的查询模式。

老王是我们业务部的老员工，干销售分析干了八年，对数据敏感，但就是不会写SQL。以前他要什么数据，得在即时通讯工具上喊我，我等手头的事忙完了再帮他跑。运气好的话一个小时内能拿到，赶上我开会可能得等半天。

这次我帮他配好Profile之后，让他自己在Database Actions的SQL窗口里试。以下是他的真实操作记录：

**第一个问题：**

```sql

SELECT AI how many customers do we have;

```

返回：425个客户。他点点头，说对。

**第二个问题：**

```sql

SELECT AI show me the top10 customers by total purchase amount;

```

返回了一个表格，客户ID、姓名、总消费额，按降序排列。他扫了一眼，第一名的客户是意料之中的那几个大客户。

**第三个问题：**

```sql

SELECT AI what were monthly sales in2023, broken down by region;

```

这次返回的数据量比较大，12行×4个区域。老王盯着屏幕看了几秒，说"以前要跑这种数据我得排两天的队"。

**第四个问题他开始上难度了：**

```sql

SELECT AI which products have the highest return rate in the east region;

```

这里我本来有点担心——"return rate"不是这张表里的原始字段，它是退货数量除以销售数量算出来的。LLM能不能理解这个计算逻辑?

结果它生成的SQL是这样的：

```sql

SELECT p.product_name,

COUNT(CASEWHEN s.status = 'RETURNED'THEN1END) * 100.0 / COUNT(*) AS return_rate

FROM sales s

JOIN products p ON s.product_id = p.product_id

JOIN customers c ON s.customer_id = c.customer_id

JOIN countries ct ON c.country_id = ct.country_id

WHERE ct.region = 'East'

GROUP BY p.product_name

ORDER BY return_rate DESC;

```

不仅正确地推导出了return_rate的计算公式，还把四张表自动关联起来了。我自问如果是自己手写这条SQL，也得想一下表关联关系。LLM在几秒内就完成了。

老王试了大概十五分钟，查了七八个问题，每个都拿到了答案。他回头跟我说了一句让我印象很深的话："这玩意儿要是早来两年，我以前那些分析报告自己就能写了。"

## 对话模式：会"记住"上下文的查询

单条自然语言查数据库已经很方便了，但真正让效率上台阶的是对话模式。

开启 `conversation: true` 之后，Select AI会记住同一个会话里之前的问题和回答。这意味着你可以像和人聊天一样追问。

比如：

```sql

SELECT AI how many new customers did we acquire in Q1 2024;

```

返回：328个。

然后接着问：

```sql

SELECT AI how does that compare to Q4 2023;

```

它知道"that"指的是Q1的新客户数，会生成一个对比查询。再接着问：

```sql

SELECT AI what about the same quarterlastyear;

```

"what about"和"same quarter"这些含糊的表达，LLM都能正确理解。它生成了一条带时间条件子查询的对比SQL，把2024年Q1和2023年Q1的新客数都查了出来。

这个能力在报表分析场景下特别实用。以前要跑一个趋势分析，你得先想好要哪些维度、怎么写SQL、跑出来不满意再改。现在可以像对话一样层层深入：先问总数，再按维度拆分，再对比上一期，再筛选异常值——每一步都在之前结果的基础上推进。

不过对话模式有个使用边界需要知道：它记住的是你在这个session里问过的问题和生成过的SQL，不是数据库里真实数据的"状态"。如果你问了"昨天的销售额"，然后又执行了一条 `UPDATE` 把昨天的数据改了，再追问"那环比呢"，它不会知道你改过数据——它只是基于当前数据重新查。

## 对SQL学习者的意外好处

在推广Select AI的过程中，我发现了一个意料之外的用途：教人学SQL。

`explainsql` 这个action会把你问的自然语言转成SQL，然后用自然语言解释这条SQL在干什么。

比如我问：

```sql

SELECT AI explainsql which products have inventory below reorder level;

```

它会返回类似这样的内容：

> 这条SQL从products表中查询库存量低于再订购水平的产品。它使用了一个简单的WHERE条件 `inventory_quantity < reorder_level` 来过滤数据，然后按产品名称排序以便查看。

对于想学SQL的业务人员来说，这种"我要什么→看看系统生成的SQL长什么样→读它的解释→理解逻辑"的循环，比任何SQL教程都直观。因为问题是你自己提的，SQL对应的是你真实的业务场景。

我让部门里一个新来的数据分析师用这种方法学SQL。他每天把工作中要查的问题用Select AI跑一次，先看结果对不对，再看 `showsql` 生成的SQL，看不懂的地方再用 `explainsql` 读解释。两周之后，他已经能自己写一些简单的单表查询了。一个月之后，多表JOIN也基本掌握了。

要说这是Select AI的"副作用"也好、"隐藏功能"也好，我觉得它对团队最大的价值不一定是"替代SQL"，而是"降低SQL的学习门槛"。

## RAG：让AI看懂你的业务文档

NL2SQL能查的是数据库里的结构化数据。但企业里还有大量非结构化数据——操作手册、制度文件、合同模板、产品说明书——这些东西也在业务人员的日常工作里，却从来不在SQL能查到的范围内。

Select AI的RAG(Retrieval Augmented Generation，检索增强生成)功能就是解决这个问题的。

RAG的原理说起来不复杂：先把文档切分成段落，用嵌入模型转成向量，存到Oracle数据库的向量索引里。当用户提问题时，系统把问题也转成向量，跟索引里的文档向量做相似度搜索，找到最相关的几段内容，连同问题一起发给LLM，LLM基于这些内容生成回答。

说白了，就是把企业文档变成了LLM可以"实时查阅"的知识库。

配置RAG比基础NL2SQL多几步。先要创建一个向量索引：

```sql

BEGIN

DBMS_CLOUD_AI.CREATE_VECTOR_INDEX(

index_name => 'PRODUCT_DOCS_IDX',

attributes => '{

"vector_db_provider": "oracle",

"location": "https://objectstorage.xxxx",

"object_storage_credential_name": "OBJ_STORAGE_CRED",

"vector_dimension": 1536,

"vector_distance_metric": "cosine",

"chunk_size": 500,

"chunk_overlap": 50

}'

);

END;

/

```

然后在AI Profile里加上 `vector_index_name`：

```sql

BEGIN

DBMS_CLOUD_AI.CREATE_PROFILE(

profile_name => 'SALES_ANALYST_RAG',

attributes => '{

"provider": "openai",

"credential_name": "OPENAI_CRED",

"model": "gpt-4o",

"object_list": [{"owner": "SH", "name": "customers"}],

"vector_index_name": "PRODUCT_DOCS_IDX",

"comments": true,

"conversation": true

}'

);

END;

/

```

配置好之后，查询时用 `narrate` action：

```sql

SELECT AI NARRATE what is the returnpolicyfor electronics;

```

它会在向量索引里搜到产品手册里关于退货政策的章节，然后基于这些内容用自然语言回答。

我在测试环境里放了十几份PDF——产品手册、价格政策、促销规则。效果比我预期的好。问"春节促销的折扣规则是什么"，它能把规则原文摘要出来并加上解释。问"电子产品退货期限和生鲜退货期限有什么不同"，它能从不同文档里提取信息做对比。

这个功能对于一线业务人员来说特别实用。他们不需要去OA系统里翻半天制度文件，也不需要记住几十页的规则手册，直接在同样一个自然语言查询界面里就能问到答案。

## 不止于查数据：Select AI的其他能力

Select AI在26ai版本里还集成了几项额外能力，虽然不如NL2SQL和RAG用得频繁，但在特定场景下确实能解决问题。

**合成数据生成(SDG)**用于生成测试数据。比如开发环境需要一批模拟的客户数据来测试新功能，但又不能用生产数据(涉及隐私合规)，就可以让Select AI生成：

```sql

SELECT DBMS_CLOUD_AI.GENERATE_SYNTHETIC_DATA(

profile_name => 'SALES_ANALYST',

object_name => 'customers',

record_count => 100,

params => '{"sample_rows": 20}'

);

```

它会基于真实客户的统计特征生成100条模拟数据，字段结构一致、数据分布相似、但内容完全是生成的。对于开发测试来说够用了，而且避免了敏感数据扩散的问题。

**文本摘要和翻译**我也试过。Select AI可以摘要最长1GB的文本(比如一本操作手册的PDF)，也可以把查询结果翻译成另一种语言。

```sql

SELECT AI SUMMARIZE '请在这里粘贴一篇长文档的文本内容……';

```

翻译功能基于OCI的翻译服务，我测试了一下中英文互译，质量还不错。英文产品描述翻成中文，不需要专门找翻译了。

## Select AI Agent：更复杂的自动化

NL2SQL解决的是"查数据"的问题，RAG解决的是"查文档"的问题。但如果业务流程涉及多个步骤——查数据→分析→发通知→更新状态——就需要Select AI Agent了。

Select AI Agent本质上是基于ReAct模式(推理+行动循环)的自治智能体。它接收一个目标，然后自动规划步骤、调用工具(SQL查询、RAG搜索、Web搜索、邮件通知等)、根据观察结果决定下一步做什么，直到目标达成或需要人工介入。

举个例子：Agent团队里可以定义一个"运营分析师Agent"负责查数据，一个"通知Agent"负责发邮件。当用户说"检查库存并通知低于安全库存的产品的采购负责人"，分析师Agent去查数据库，通知Agent把结果用邮件发出去。

配置方式是通过 `DBMS_CLOUD_AI_AGENT` 包：

```sql

BEGIN

DBMS_CLOUD_AI_AGENT.CREATE_AGENT(

agent_name => 'InventoryMonitor',

attributes => '{

"profile_name": "SALES_ANALYST",

"role": "You are an inventory monitoring agent..."

}'

);

END;

/

```

不过老实说，Agent的功能我还在摸索中。它的配置链路比较长——要先建Agent、再建Tool、再建Task、最后组建Team——而且目前主要在Autonomous AI Database上跑得更顺。如果我装的是本地的Oracle AI Database 26ai，有些Agent功能可能受限于版本。

如果你刚接触Select AI，建议先从NL2SQL开始用，把基础配置和查询准确率调稳了，再考虑Agent。

##使用Select AI要注意的几个问题

写了这么多优点，也该说说它的局限和坑。免得有人看完上头了直接上生产，然后回来骂我。

**第一，NL2SQL的准确率不是100%。** 在我的测试中，简单问题(单表聚合、条件过滤)几乎全对。中等复杂度的问题(多表关联、窗口函数、CASE WHEN)大概有90%的准确率。复杂问题(多层子查询、PIVOT、涉及业务规则推导)大概在70%-80%。问题越模糊，准确率越低。所以对于关键业务报表，建议开启 `showsql` 让业务人员确认SQL再执行，或者让DBA对生成的SQL做把关。

**第二，LLM的响应有延迟。** 从发送自然语言到LLM返回SQL、再到数据库执行返回结果，整个过程快则2-3秒，慢则5-8秒。对于临时查询来说完全可以接受，但对于高频的实时接口调用不合适。OLTP场景不适合用Select AI。

**第三，权限控制要提前想好。**`object_list` 限制了LLM能"看到"哪些表，但一旦配置了某个表，LLM就能查询这张表的全部数据(符合数据库用户权限的前提下)。如果需要更细粒度的行级或列级权限控制，必须在数据库层面通过视图或虚拟列来实现。

**第四，凭据安全管理。** API key直接写在 `CREATE_CREDENTIAL` 的参数里，如果数据库的审计日志开了，key会被记录在日志里。建议用Oracle的密钥管理服务或者外部凭据存储来管理敏感信息。

**第五，LLM的token消耗。** 每次查询都会消耗LLM的token，虽然生成SQL的消耗通常不大，但如果并发用户多了，每月API账单会是一笔不容忽视的开支。我建议按实际使用量估算后再决定用哪种计费方式。

**第六，Dialect问题。** Select AI目前不支持指定SQL方言。如果你用的是Oracle兼容模式下的KingbaseES或者MySQL，生成的Oracle语法SQL可能跑不了。

## 对DBA角色的影响

有人问过我：Select AI普及了，DBA是不是就要失业了?

我的看法是不太会。

DBA的工作可以分成三层。最底层是"跑SQL查数据"，中间层是"SQL优化和调优"，最上层是"数据架构和治理"。Select AI替代的是最底层的那部分——替业务人员写SQL查数据。这部分工作本身就不是DBA的核心价值所在。说句不好听的，每天花一两个小时帮业务部门"跑个数"，对职业成长也没什么帮助。

DBA真正的价值在上层：设计表结构、优化查询性能、保障数据安全、规划容量、搭建高可用架构。这些事Select AI替你干不了，反而因为业务人员能自己查数据了，DBA有更多时间去处理真正重要的系统性问题。

不过DBA的技能树确实需要扩展了——以前只要懂SQL和数据库原理，现在还得懂LLM配置、向量索引、提示词工程。我在调试Select AI的过程中，花了不少时间在调整AI Profile的参数和优化表的注释上，这些经验以前不在DBA的知识体系里。

## 总结

我把Select AI给老王用了两个月之后，问了他一个简单的问题：你觉得这个东西和以前有什么区别?

他想了想说："以前我想到一个问题，第一个念头是‘这数据能不能拿到?拿到要多久?’现在想到问题，第一个念头是‘这个问题本身对不对’。"

我觉得这个回答很到位。Select AI真正改变的不是写SQL的方式，而是思考问题的方式。当数据的获取不再是瓶颈，业务人员会花更多时间去思考业务本身——什么指标是真正重要的、什么维度的分析能带来洞察。

当然，Select AI不是完美的。它偶尔会生成错误的SQL，对模糊问题的处理不够稳定，对数据安全和凭据管理的要求也比传统方式高。但它代表了数据库交互的一个明确方向——从"人学机器语言"到"机器理解人的语言"。

Oracle在26ai这个版本里把这个方向往前推了一大步。作为一个从Oracle 9i时代就开始用Oracle的人，我看过太多"颠覆性"的新功能最终没有落地。但Select AI不太一样，它解决的是一个真实存在的、每天都有人在面对的痛点——数据在库里，但拿到它太难了。

如果你手头有Oracle AI Database 26ai或者Autonomous AI Database的环境，我建议你花一两个小时搭一套Select AI试试。配一个最小的Profile，连一个便宜的LLM(比如OpenAI的gpt-4o-mini，token成本很低)，让一个完全不写SQL的业务同事上去跑几个问题。你大概会和我一样，被"非技术人员自己查到了数据"那一刻的表情打动。

那就是Select AI存在的意义。