随着 AI 技术的兴起，数据库正面临前所未有的挑战。向量、图和多模态数据等新对象进入生产链路，GPU、RDMA 等硬件成为系统设计的关键变量。AI Agent 的持续工作模式要求数据库能够处理更复杂的任务链，而不仅仅是简单的 SQL 查询。腾讯云数据库 DBTalk 在“顶会三连击”中展示了最新的观察，强调了从系统演进到云原生数据基础设施再到测试与测评的全面变革。这些变革要求数据库的基本能力保持不变，但必须适应新的数据表示、存储格式、优化器与执行引擎的设计。张峰教授提出了数据库内核协同演进的观点，指出系统优化应围绕数据路径展开，包括数据如何表示、布局、移动、执行以及在负载变化时的稳定性。李环研究员关注云原生数据基础设施的变化，强调资源池化和 Serverless 数据服务的重要性，并讨论了资源边界的独立化和弹性问题。杨程程研究员则从测试与测评角度出发，提出需要重新定义 Benchmark 来评估 AI 负载下的性能。最后，企业与高校之间的合作对于理解新工具带来的问题至关重要，同时确保研究成果能够真正应用于生产环境。

--91likeyou---

数据格式就是一个典型例子。以 L3 为例，在 GPU 时代，压缩率高并不等于算得快。若仍沿用 CPU 侧编码、CPU 与 GPU 之间搬运、执行时再解码的传统路径，压缩带来的收益很容易被数据转换和搬运成本抵消。L3 因此重新设计 GPU 原生的数据格式，使学习型压缩从 CPU 侧的离线处理，转变为能够直接参与 GPU 分析计算的可执行数据格式。

类似的变化也发生在向量和图数据系统中。向量数据库需要同时考虑检索、分区、负载倾斜与跨机通信；压缩图直接更新则通过前台完成轻量级局部修改、后台持续整理压缩规则，在保持压缩效果的同时兼顾在线更新与查询性能。

当数据类型不断增加、访问路径持续延长，数据库优化的目标也随之变化：不再只追求单个模块的局部最优，而是围绕真实工作负载，推动数据表示、执行引擎与异构硬件的跨层协同。

资源能够解耦，弹性却不会自然发生

如果说数据库内核需要适应新的数据对象和访问方式，那么云原生数据基础设施面对的另一项挑战，是数据库运行方式本身的变化：资源边界已经逐步打开，但资源池并不会自动产生弹性。李环关注的是数据库运行方式的变化。

近几年，云原生数据库沿着存算解耦、资源池化和 Serverless 数据服务持续演进。持久数据与计算节点不再被严格绑定，内存、缓存以及压缩等后台任务也开始拥有更独立的资源边界。容量规划、扩缩容、查询准入和资源配置，随之从 DBA 的离线操作逐步转变为系统持续执行的在线决策。

不过，资源能拆开，不代表弹性问题已经消失。远程访问会带来网络开销；新节点加入后，需要完成状态恢复和拓扑收敛；缓存扩缩还会影响命中率与一致性。真正的弹性不能等负载爆发后再补救，而要在观测、预测、决策、执行和反馈之间形成闭环。

李环将这一目标概括为“快、稳、省”。“快”，是资源能否及时到位，以及运行中的查询能否利用新增算力；“稳”，是多租户、多并发场景下的准入、过载保护与服务等级目标；“省”，则是资源能否按查询需求被细粒度分配和复用。三者并不能同时无限优化，系统需要在响应速度、稳定余量和资源利用率之间寻找合适的控制点。

Agent 的出现让这道题更复杂。计算资源可以回收，但任务进度、长期记忆、执行分支和权限上下文不能随之丢失。未来的数据基础设施，需要管理的不只是 CPU、内存和存储，还包括跨越多次查询和工具调用的任务状态、数据生命周期、访问关系等。

长链路任务，不能只靠单点指标证明可靠

新架构、新负载进入生产，最终都要回答一个更朴素的问题：系统究竟可靠不可靠？杨程程从测试与测评角度提出，AI 时代的 Benchmark 需要重新定义评测对象。

传统 Benchmark 往往以查询或事务为基本单元。但一次 Agent 任务，可能同时包含向量检索、结构化查询、记忆读取、数据更新和多轮工具调用。这意味着，面向 AI 负载的测评至少需要覆盖 5 个方向。

评测单元从算子升级为工作流。传统 Benchmark 以查询或事务为基本单元，但 AI Agent 的一次任务往往包含向量检索、结构化查询、记忆读取、数据更新和多轮工具调用。Benchmark 不应只测单个算子有多快，更要评价这些操作组合后的端到端性能，以及不同数据访问路径之间是否产生资源竞争。

多模数据需要协同访问。AI 任务常同时涉及关系数据、向量、文档甚至图数据。Benchmark 应评价混合查询下的吞吐、延迟和资源开销，而非将每种能力割裂测试。

负载与状态会持续演化。Agent 的记忆持续增长，访问模式随任务阶段不断变化。Benchmark 应设计从冷启动、稳定运行到数据增长、突发并发的多阶段负载，评价系统在变化中的性能退化、恢复能力和资源弹性。

多租户隔离必须经受真实压力。真实平台同时服务大量 Agent，负载差异巨大。Benchmark 应评价租户间的干扰程度，以及系统在有限资源下能否维持稳定的服务质量。

异常必须能够拆解。当系统表现异常时，Benchmark 应能帮助定位问题发生在哪个环节——是检索慢了、生成超时了，还是工具调用卡住了，而不是只给出一个总分。这种模块化的拆解与追溯能力，是系统从“可用”走向“可信”的关键。

AI 时代，数据库要管理的不只是数据

圆桌讨论将话题落回到研究与工程之间的关系。企业带来真实场景、复杂边界和持续的工程反馈；高校则从中抽象出可验证的问题，探索更具通用性的解法。两者之间的往复，决定了许多系统研究能否真正走进生产环境。

对研究者和工程师而言，AI 与数据库的交叉会不断带来新问题，但系统基本功仍然不可替代。理解数据表示、执行引擎、并发控制和软硬件协同，才能在新工具不断出现时，判断瓶颈究竟在哪里。

数据库的下一站，不是功能清单的继续增长，而是一场跨层重构：数据表示要适应新对象，资源管理要感知新负载，测试与测评要覆盖新边界。当数据库既能管理数据，也能更好地管理状态、记忆与任务生命周期，它才可能成为 AI 时代更可靠的数据底座。

🔥 热词：#当 ai 开始重写负载,数据库该如何重新设计 · #用ai写数据库 · #ai重构软件 删代码问题 · #怎么用ai改数据库数据 · #数据库在ai中的作用 · #Ai本地数据库方案 · #ai数据库有多厉害 · #ai的数据库有多大