2026DTCC大会顺利举行，美创科技产业教育中心执行院长施嘉伟受邀参加，作为DTCC大会的“老朋友”，结合大会整体议题及自己从业经验，写下如下感悟：
今年参加 2026 中国数据库技术大会，多了个身份，Data+AI 专场主持人。
做数据库这些年，大会没少跑。前几年是国产化、分布式、云原生、HTAP。今年再看，Data+AI 已经铺到好几个分会场。
主持那半天，我既要盯流程和时间，也要听台上讲数据库、模型和 Agent。几个议题听下来，我脑子里一直有个问题：库越来越聪明，运维能不能轻松一点？
至少眼下不会。AI 能减少一部分重复劳动，同时也把更多系统带进了运维范围。
过去几年，数据库和 AI 放在一起讲，重点几乎都在用 AI 把库管好。辅助诊断、SQL 优化，今年还有人讲，也还用得上。今年多了一类议题：数据库怎么把 AI 应用撑住。
AI 一旦进了企业，要处理的数据和传统业务差得很远。以前主要是结构化业务数据，字段清楚，模型固定。现在多出来文档、向量和上下文，很多东西没法直接建表。数据库照样要管存储、查询和事务，还得思考几个新问题：模型用的数据从哪来，谁能取，取走之后有没有留痕。
安全这条尤其麻烦。公安、医疗这些行业，核心数据不能出域，知识库只能建在内网。权限没收干净的话，一个检索接口就可能把分属十几种角色的数据一起交给模型。接上 AI 以后，原来权限没管住的数据，模型也能看见。
以前企业数据架构一张图能讲完。应用连数据库，数据库管存储和查询。AI 进生产之后，这条链被拉得很长。业务库、知识库、向量检索、对象存储、大模型服务，再挂上 Agent。一套应用七八个组件，已经不稀奇。
组件一多，接缝就多。数据怎么同步，权限在哪一层收口，出事了从哪查起，这个组件归谁管。做过跨组件排障的都知道，很多时间都耗在没人认领的那一段。各个组件可能都没报错，业务却跑不通，几个团队一时也说不清该由谁处理。
这两年，数据库厂商开始把向量检索等周边能力收进产品。功能放进同一套产品后，运维照样要处理数据同步、权限和故障定位，只是需要多盯一层。
这个问题每隔几年就来一遍。云数据库来的时候问过，库开始讲自治的时候又问过。现在轮到 AI。
大模型和 Agent 越做越强，库能不能自己诊断、自己处理故障？不过我偏保守，目前看起来还很难。
我们可以先把一部分重复劳动交给 AI。查日志、翻指标、看执行计划、写报告，都适合让工具来做。
可在生产上守过夜的人都清楚，复杂故障很少只有一个标准答案。库慢了，原因可能压根不在库上。存储和网络都有可能，连接池、某条 SQL、某个锁都有可能。还有一种更窝火：前一天晚上业务发了个版本，库这边看起来像无故变慢。你按库的思路查下去，最后根因在程序变更。
企业里同时跑好几套库，排查起来更麻烦。优化器、备份恢复机制，各家都不一样。同一个现象，放到两套库上，根因可能完全不同。再接上 AI 的数据链路，要查的范围又往外扩了一层。
现在做数据库技术服务，不是维护好一种数据库就好了。一个企业内部，商业库、开源库、国产库、云上实例同时在跑，已经很常见。各有各的历史原因，不可能为了方便运维就全部换成一种类型数据库。手上还压着国产化迁移、版本升级、容灾和安全治理。到了 Data+AI，运维又要接触知识库、向量检索和模型服务。故障一来，团队很难一眼判断该找谁。
业务响应慢，可能要找 DBA，也可能要找开发，网络和存储团队也经常被拉进来。AI 应用效果突然变差，还得检查模型、数据、索引，以及底层表最近有没有变更。只盯着某一款数据库，常常查不到根因。
工程师也得多懂几层。除了装库、备份和调参数，还要懂 SQL、架构、操作系统和存储。再往上，至少要看懂 AI 应用怎么用数据，向量检索在干什么，RAG 的数据怎么流。Agent 为什么需要那么多上下文，我以前没怎么认真想过。今年听下来，这个问题躲不开。
专场里有一场讲企业级大模型落地，主要谈的是成本。
这些痛点很眼熟：API 调用和推理的账单压不住，核心数据不能出域，通用模型又不懂行业门道。企业想自己调优，还要考虑能不能养得起团队。
嘉宾老师给的原则很直接：先 RAG，搞不定再微调，最后才做全量训练。目标是用十分之一的成本做出一套够用的方案。讲师还介绍了几种具体做法，PEFT 把原模型冻住，只训很少一部分参数，通过量化缩小模型，再把推理放到边缘设备上，数据也能留在本地。
各位同行，这个处理思路是不是很熟悉？跟处理数据库问题差不多。先看 SQL、加索引，不行再调参数，再不行才动表结构和架构。每往下一步，成本和风险都会增加。层级判断错了，团队可能把一个加索引就能解决的问题，折腾成一次架构改造。是不是几乎就是数据库优化的日常。
这场大模型成本分享里，有接近一半的内容都在讲数据怎么组织。RAG 要走通，私有化知识库得先建起来。数据要留在域内，权限要收得住，知识内容变化后，索引还要及时更新。最后接下这些活的，还是数据库和数据团队。
AI 最实在的好处，是查资料没那么费劲了。以前碰上没见过的报错，要翻官方文档，搜知识库和社区，再结合现场慢慢试。现在把日志、报错和执行计划交给 AI，很快就能拿到几条像样的排查思路。
拿到建议以后，现场工程师还要做变更评估。AI 说某个参数可以调，工程师得判断现在能不能改、会影响哪些业务、有没有联动参数。换一套环境，答案可能完全不同，回退方案也要结合现场环境来制定。
数据库存的是企业最核心的数据。一次误操作造成的影响，跟普通应用故障不在一个量级。方案写得再好，进生产前该走的评审、验证和回退都省不掉。我也没见过哪家会因为模型强大，就跳过变更窗口。该有的步骤一个都不能少！
以前做巡检、翻日志、写报告，很多时候都靠工程师自己来。现在，不少工作可以交给自动化工具和 AI，比如信息收集、初步诊断和方案初稿。
工程师可以把省下来的时间用在复杂故障判断、容灾设计和迁移割接上。AI 能整理材料、补充检查项，也能列出风险。方案能不能用，还得看业务影响和变更窗口，最后由工程师来定。
美创这几年做数据库服务，也在把 AI 接入巡检、日志分析和报告整理。工具先处理重复工作，工程师盯复杂故障和重大变更。客户最后看的是结果：问题发现得是否及时，排查和处置问题快不快。
每年参加数据库大会，议程上都会换一批新词。今年国产化还在推进，Data+AI 又成了焦点。企业最后关心的还是那些具体问题：数据不能丢，权限不能乱，业务还得稳定运行。
AI 能帮运维省下不少重复劳动。故障一旦牵扯数据库、存储、检索和模型服务，工程师仍要把整条链路串起来排查。今年参加 DTCC 之后，我更确定数据库运维的范围还会继续往外扩。以后接到一个“数据库慢了”的电话，我们可能要从应用一路查到存储、检索和模型服务。
施嘉伟：
美创科技产业教育中心执行院长/技术运维部经理，Oracle ACE Pro、PostgreSQL ACE，OCM/PGCM/KCM认证。 IvorySQL 专家顾问委员、KVA、崖山YVP、KWDB MVP、PolarDB开源社区/HaloDB技术顾问、TiDB社区技术布道师、青学会MOP技术社区专家顾问。
浙公网安备 33010502006954号 
