应用层的焦虑已经蔓延到最底层：应用被逆向、老软件被重造，那垫在所有软件下面的数据库呢？结论先说——基本盘没被动摇，但 AI 给数据库派了四道新考题，答不答得上，决定下一阶段的座次。
基本盘：AI 动不了的那部分
企业里有些账，大模型再聪明也不能编：昨天卖了多少货、库存还剩多少、供应商的款到账没有。这些数要实时、可靠、可恢复，OLTP 和 OLAP 的刚需一点没变。生产数据仍会待在数据库里，这条底线由"一致性"保证，不由模型保证。
变的是甲方名单。以前数据库服务开发者和业务系统，现在多了一个笨手笨脚的新用户：AI。它有三宗"笨"——看不懂 Schema 背后的业务语义；用数据要先导出、加工、向量化再搬进另一套系统，而且数据天天变、天天搬；老管理工具是给资深 DBA 设计的，AI 既不会用，更怕它乱用。
四道新考题
语义层。把表结构背后的业务含义（字段口径、约束关系、脏数据规则）显式化，让 AI 能读懂"这个库在管什么生意"。配套工具是 NL2SQL 智能体和运维智能体：前者把业务问题转成查询，后者做巡检、诊断和修复辅助。
库内计算。与其把数据搬出去向量化，不如让计算下沉到数据所在处，减少那条天天跑的搬运管道。语义检索、库内特征工程是这条线的第一批落地。
AI 安全。这是最容易被低估的一道。AI 有了查库能力，攻击面跟着变了：提示注入可能诱导 Agent 执行危险查询，过度授权会让一次误判变成一次数据泄露。防护思路是给 AI 的数据库账号单独建最小权限集、高危操作走人工确认，而不是复用 DBA 的旧钥匙。
多模态。文本之外的图片、音频、日志进入分析范围，向量检索只是入口，库内的多模索引与混合查询是后续深水区。
对开发者的落地建议
增量提醒（原文没有的操作视角）：如果你的团队正在把 Agent 接到生产库上，验收清单至少四条——AI 专用账号的权限表人工过一遍（只读起步，写权限逐项审批）；提示注入红队测试（在用户输入里夹带"删除所有订单"类指令，验证被拦截）；慢查询与危险语句审计日志独立存放且不可被 AI 触达；NL2SQL 生成语句先 EXPLAIN 后执行，全表扫描与无 WHERE 的 UPDATE 直接拒绝。四条不过，宁可先接只读副本。
数据库这门生意的答案是能干，前提是学会新手艺——以前是"被人用"，往后要经得起"被 AI 用"。工具侧的适配（MCP、Agent Skills、主流框架接入）已经动起来，选库时多问一句"AI 用起来顺不顺"，两年后回头看会省很多迁移成本。
评论0