数据库圈里今年谈DB4AI和AI2DB的比较多，大家谈的大多数是一些场景和功能，不过如果深入做进去，才会发现无论是DB4AI还是AI4DB，可能都有“单相思”的毛病。前阵子我写过文章，说数据库厂商设计DB4AI的功能的时候，并不理解AI应用需要DB提供什么样的功能。今天我想聊一聊，AI4DB同样也存在类似的问题。

AI能为DB做很多事情，但是DB可能不知道，也可能不一定会领情。因为在AI为DB提供一些能力支撑的时候，DB厂商也需要做大量的工作来迎合，才能做出效果来。最简单的一个例子是如果我们要做一个国产数据库的知识问答，我们就会发现，手头的知识素材太少了。哪怕我们能搞到一些国产数据库的官方文档，这些文档的内容覆盖和文档质量可能也存在问题。最关键的是，这些文档中缺少高质量的使用案例和使用经验。在国产数据库中还有一个十分奇怪的现象，那就是BUG报告绝对是不能在官网上发布的，否则会被友商拿去作为商务武器，在用户侧诋毁其对手。而在现阶段，BUG报告的价值是相当大的。想想Oracle MOS上上百万份BUG报告，再看看国产数据库的现状，这的令人唏嘘。

文档还只是一个小的侧面，国产数据库的可观测性方面的数据缺失是更大的问题。很多国产数据库在设计运维模式或者可观测性接口的时候，大多数是以传统的(就AI时代来说，是落后和不适配的)方式，当数据库出问题的时候，通过开一些跟踪项，通过日志去定位或者分析问题。因此虽然目前绝大多数国产数据库都模仿了Oracle的AWR/ASH/ADDM报告的功能，但是几乎都是花架子，缺乏高质量数据作为支撑的这些报告，就连原厂的售后人员都很少会主动用来定位问题。

我们一直在说，数字化是智能化的基础，但是可能大家意想不到的是，作为数字化的核心基础设施的数据库，其数字化程度居然那么低，当日这句话不是指O记，而是指我们的国产数据库。最近我们和一些国产数据库厂商合作做运维智能体，工作中就发现了很多因为某些指标的缺失，导致智能体的分析结果大打折扣。幸运的是，大多数国产数据库遇到这方面的问题的态度是十分积极的，他们会和我们积极探讨问题所在，考虑他们如何去提升可观测性能力。不过也有一些厂商的同学会觉得他们设计的指标体系的时候是经过深思熟虑的，缺失的这些指标对运维分析影响不大。而事实上，如果缺失了某些指标，那么遇到问题的时候，如果不交给原厂的研发去分析，还真的很难定位问题。他们说这样的话，要么是自己都没有意识到这些指标对DBA来说有多重要，要么是手头的工作压力太大，目前还无暇顾及这些“细枝末节”。

实际上，如果是可观测性方面的功能缺失，要修改起来，比编写文档要困难得多，很多功能需要对数据库内核做大手术才行。比如有些数据库设计的SQL信息表里缺乏完整的SQL语句，要想采集到完整的语句，必须打开某个默认不打开的开关，打开开关之后对应用系统的影响也是未知的，那么用户可能无法下决心来打开这些开关。而如果采集不到完整的SQL语句，那么TOP SQL的智能化优化如何开展呢?

现在大家都说智能化时代来临了，我最近接触的客户，几乎都在尝试一些智能化的工作，很多客户已经意识到了，搭一个DEMO出来不难，要深入做下去，就发现很多地方做不动了。做不动的原因很多，不过很大一方面的原因是数据库本身不是AI READY的，在功能上缺失对AI的支持能力。想要在AI时代实现AI4DB，还需要来一场双向奔赴，数据库也要向AI走两步才行。