Oracle 26i 的一个功能演进后，云厂商利用会不会造出千年老妖样的“数据库”

liuaustin32025年10月28日约 17 分钟

❝
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群近400 9群 200+，开10群PolarDB专业学习群100+)

最近参会和一些老师学了不少，其中我记忆深刻的是白鳝老师在会上对Oracle26i的一个功能的深刻理解后的直白输出。

Oracle26i打造的是一个AI数据库平台，其中有一个功能叫 ‘Annotations’,中文翻译过来叫“释义”。这个功能主要的用处并不是和我们数据库中的对，表，字段的一个comments，那么comments 和 Annotations，之间最大的不同是什么，我们可以从这里进行一个深入的思考。

1 comments 仅仅是针对数据库字段和表的一个意义的注释。Annotations是一个深入化的comments，或者一个别有企图和后续为AI 自治ORACLE数据库做一个好的基础。

Annoations的形式：支持 “键值对”（如 Description '主键'）或单独的 “键”（如 Primary Key），适用对象：覆盖表、索引、域（domains）、列等多种数据库对象，灵活性：无数量限制，键的最大长度可达 1024 字符，核心价值：能将数据模型与元数据 “统一存储在数据库内”，确保应用与开发者共享一致的信息，解决传统注释信息零散的问题。

这里我想引入一段我最近对AI 优化SQL的经验，在去年很多博主都吐槽AI对SQL优化的“胡说八道”，而今年这样的博主明显少了许多，抛出去一部分这样的问题说烂了。

另一个原因是AI优化SQL，正确率和实现的靠谱性，已经让一些老DBA也无话可说了。

优化SQL 没头脑的进行SQL优化

这里一般人优化SQL，大部分情况是讲SQL扔给AI，让AI来进行SQL的优化，但我们需要明晰一点，AI做任何事情都是要有数据的支持和支撑的，你只把SQL给了AI，他有很多东西是不清楚的。

我们可以梳理一下，我们缺少了什么

1 表的功能

2 表字段的功能

3 SQL语句

4 语句执行的当前计划

5 语句的功能描述

6 每个字段，每个表的数据量，以及字段的采用动态分布。

7 针对某个SQL的具体的业务功能描述。

这里我们注意，因为我们缺失了很多的信息，所以导致SQL的优化并不让人满意，但你要知道你问的是AI 不是算命先生。你啥都不给他，你让他给你盲人摸象，这属于上梁不正下梁歪。

而如果我们把一些信息给全了，那么AI的优化结果就会变得，越来越正常，越来越让人刮目相看。

这里我试着讲给出的信息，逐步详细，从只给SQL语句，在到给出语句的执行计划，在到给出每个参与SQL的表的行数，在到每个查询条件中的采样率，在将每个表的表结构，都放到一起，贴给了AI.

AI 每次给出的优化建议都更加详细，每次给出的意见都比原来的要多，最后给出了

1 执行计划的分析

2 执行计划中，消耗cost 最多的原因

3 指出SQL执行中表缺少的索引

4 告知SQL的集中重写的逻辑写法，并告知每个写法的修改的主要原因。

 -> Sort: <temporary>.seqnum, <temporary>.id  (actual time=16490.784..16490.791 rows=51 loops=1)
    -> Table scan on <temporary>  (actual time=0.002..0.010 rows=51 loops=1)
        -> Temporary table with deduplication  (actual time=16490.740..16490.758 rows=51 loops=1)
            -> Filter: ((cus.privateproductflag = 1) or true or (rpcode.id is not null))  (cost=262.14 rows=324) (actual time=1.833..15129.564 rows=2070783 loops=1)
                -> Nested loop left join  (cost=262.14 rows=324) (actual time=1.831..14636.852 rows=2070783 loops=1)
                    -> Nested loop inner join  (cost=146.53 rows=17) (actual time=0.660..3987.231 rows=2070783 loops=1)
                        -> Nested loop inner join  (cost=140.71 rows=0) (actual time=0.370..18.156 rows=1609 loops=1)
                            -> Nested loop inner join  (cost=140.70 rows=0) (actual time=0.230..14.388 rows=352 loops=1)
                                -> Nested loop inner join  (cost=140.64 rows=0) (actual time=0.220..12.281 rows=352 loops=1)
                                    -> Nested loop inner join  (cost=140.58 rows=0) (actual time=0.092..8.471 rows=352 loops=1)
                                        -> Filter: ((p.hiddenflag = 0) and (p.showflag = 1) and (p.visibleflag = 1) and (p.disabledflag = 0))  (cost=138.58 rows=3) (actual time=0.074..1.568 rows=263 loops=1)
                                            -> Index lookup on p using syscodeid (syscodeid=816248832605159424)  (cost=138.58 rows=263) (actual time=0.073..1.371 rows=263 loops=1)
                                        -> Filter: ((rpas.disabledflag = 0) and (rpas.sellersyscodeid = 816248832605159424))  (cost=0.50 rows=0) (actual time=0.020..0.026 rows=1 loops=263)
                                            -> Index lookup on rpas using shopid_productid (shopid=866646924093296640, productid=p.id), with index condition: (rpas.productid = p.id)  (cost=0.50 rows=1) (actual time=0.020..0.024 rows=1 loops=263)
                                    -> Index lookup on rpc using productid (productid=p.id)  (cost=0.86 rows=1) (actual time=0.009..0.010 rows=1 loops=352)
                                -> Filter: ((bc.disabledflag = 0) and (bc.`type` = 0))  (cost=0.28 rows=0) (actual time=0.004..0.005 rows=1 loops=352)
                                    -> Index lookup on bc using PRIMARY (id=rpc.categoryid)  (cost=0.28 rows=1) (actual time=0.003..0.004 rows=1 loops=352)
                            -> Index lookup on pa using productid (productid=rpas.productid), with index condition: (pa.productid = p.id)  (cost=16.10 rows=1) (actual time=0.005..0.009 rows=5 loops=352)
                        -> Index lookup on cus using syscodeid (sellersyscodeid=816248832605159424)  (cost=10279.59 rows=1287) (actual time=0.158..2.220 rows=1287 loops=1609)
                    -> Filter: ((rpcode.syscodeid = cus.syscodeid) and (rpcode.sellshopid = 866646924093296640))  (cost=5.12 rows=20) (actual time=0.005..0.005 rows=0 loops=2070783)
                        -> Index lookup on rpcode using productid (productid=p.id)  (cost=5.12 rows=20) (actual time=0.003..0.004 rows=2 loops=2070783)

那么我们将ORACLE 26I的新的功能展示一下

MARCO @ DB23AI:PDB1:>create table car_vendors (
2    id         number(15)   annotations (PrimaryKey, Description 'Primary Key', Class 'Number')
3   ,vname      varchar2(30) annotations (Description 'Car Vendor Company Name', Class 'Text')
4   ,country_id number(15)   annotations (ForeignKey, Description 'ID for Country Reference', Class 'Number')
5  )
6* annotations (Description 'List of Car Vendors', Visibility 'everyone');

这是一个ORACLE的建表语句，其中使用了新的功能annotations，在这里我们可以看到大段的对这个表和每个字段的功能，以及他的定义的详述，听说甚至到索引都可以进行定义的注释。

那么为什么引入这个功能，如同白鳝老师会上提到的，Oracle在为自己的数据库打造一个AI数据库自治的I平台，在完善基础。

试想，AI读取每个表的 annotaitons,那么他将获取这个表在业务中的功能，同时也将获得这个表在SQL运行中的作用，甚至后续SQL都可以进行annotations，也就是我们每产生一个SQL，就可以在数据库里面给这个SQL一个逻辑的文字描述，说明他的功能。

这样做完后，AI将完全获取SQL的业务逻辑的可能性，并进行分析，通过业务的需求，写出SQL，修改SQL，并且从系统表中获取表的大小和一些采样分布的信息，实现大部分业务的SQL撰写，通过语言告知的模式就写出SQL，那就并不是天方夜谭了。

同时在大量用户上云后，我们也发现一个重要的部分，云上的SQL改写，SQL的索引建议，以及重复索引的提醒功能，已经是云厂商的提供的标准功能。

这里云厂商如果也模仿Oracle的annotations的功能，融合到他们的云原生数据库，那么完全自治的数据库，也可能会很快出现，因为云厂商把握的数据库的硬件，数据本身，差的就是使用数据库的人对表，字段，索引的一些业务逻辑的描述和定义，有了这些他们会比ORACLE搞出数据库AI治理，AI撰写SQL，AI自适应运维数据库做好后面的基础。

说到这里，如果我是云厂商的数据库产品经理，我会抓住这个ORACLE的功能，附加云上的优势，打造一个让数据库拥有自我描述能力的产品，数据库将从闭嘴干活，转变到，可以自我建议数据库一些业务数据，参与业务的一些表的设计的建议，甚至直接根据业务的描述，给出建表的架构。

如果更近一步，这样的数据库不仅仅可以知道怎么执行，怎么优化SQL，还可以通过这些信息，来推断你的业务是什么，为什么执行这个SQL，背后的商业逻辑是什么。

如果做到这里，你觉得，他和你在SQL优化，的准确率上，谁能更高，更快，更准确，甚至开始自问自答的方式，来管理数据库。尤其在云上的数据库产品，要做这个更是简单，更能体现云数据库的商业价值。

举一个例子，你定义个一个业务表，并明确这个是一个订单表，然后你最近的数据量在订单表上有体现，AI会不会可以开始判断你的业务最近的状态，并开始可以通过数据库做业务数据分析，最后变成一个，千年的数据库老妖怪，什么都瞒不过他。

“A database that knows itself, describes itself, and optimizes itself.”

置顶

“一顿海鲜引发”（2）“运维工具与DBA之间不打不相识”

“一顿海鲜引发”（1）：DBA、架构师与数据库运维工具的爱恨情仇

DBA 从“修电脑的” 到上演一套 “数据治理” 大戏 --- 维护DBA生存空间，体现个体价值

Oracle 也有做失败的数据库系统？是的今天我们来说说他

老板说 MongoDB 测试环境这么贵，弄单机？开发说要复制集测试？你们这群XXX！！

国庆节2号 PostgreSQL 停机罢工协助解决问题得 66.66元的红包