各位好，我是路远。搞了十五年数据库，我最怕听到的话就是“这个很简单”。

上周二晚上，一个老同事给我打电话。他做了十二年运维，最近在学AI工具。他问我，AI数据库都能看执行计划了，这行还剩下什么？他问的其实不是工具，是自己的位置。

我没急着回答，先讲了2021年大促前一个订单库的压测。监控把一条SQL排在耗时榜首。工具的建议很直接：加一个联合索引。我拉出执行计划，发现这是凌晨的对账批处理。给它加索引，白天写入先会遭殃。真正要改的，是批处理的分片方式和启动时间。后来那条SQL掉出榜单，订单写入也没受影响。

这件事让我记住一句话。工具能指出谁在花时间，说不清谁该为时间负责。AI数据库也是这个逻辑，先把诊断、调优、开发、检索接进库里。先接管的，是“找问题”；再谈“做决定”。工具把证据摆出来。证据怎么变成决定，还是人的事。这不是概念问题，是分工问题。

这两年行业里的Demo越来越顺，大家的期待也跟着涨。但生产上的活，不是答得快就算完。我把DBA的活拆成五段，逐段看AI接走了多少。先看一张分工表，后面几段按这张表逐条拆。

| DBA的环节 | AI数据库现在能接 | 还得人来做 |
| --- | --- | --- |
| 发现异常 | 采集指标、聚类告警、排出热点语句 | 判断是不是高峰期的正常波动 |
| 定位对象 | 锁定语句、会话、对象和执行计划 | 把对象放回业务节奏里看 |
| 分析原因 | 给出等待事件、资源消耗和执行路径 | 分辨批处理、锁等待和容量不足 |
| 生成方案 | 给出索引、参数和SQL改写建议 | 在影子库回放，比较前后计划 |
| 变更与担责 | 记录过程、生成脚本草稿 | 定窗口、签字、准备回滚 |

这张表说的是AI数据库和DBA的分工。能接走的就接干净，接不走的，写清楚边界。这次金仓的产品发布会和开发者大会，AI数据库是主线。金仓AI数据库这条线，也照这个分工走。落到KES上，先解决的是“看见”。

## 一、AI数据库能诊断，定责还得人

出事的时候，没人先问“哪里慢”。大家问的是“为什么还没好”。这两句话，正好对应诊断的两层。一层是找到对象，一层是判断原因。我习惯再往下拆三个问题。哪里慢、为何慢、在干嘛。

哪里慢，靠语句级热点，按总耗时和IO排。KWR做的是这件事，采集开销低，可以常开。快照分段对比，能看出问题是新来的，还是一直在。这点对复盘很关键。再看为何慢，得看函数和代码行。PLProfiler插桩之后，循环次数能看见。

在干嘛，看当前执行位置和计划状态。PLTrace轻量，SQL Monitor看得更细。这几件工具，解决的是“有没有证据”。AI数据库在这一层，接走的是“找证据”。至于证据够不够定责，是另一回事。工具不会替你在变更单上签名。证据怎么读，先看一段计划示意。数字不重要，读法才重要。

```text
Limit  (cost=0.43..812.55 rows=100 width=64)
       (actual time=0.08..186.42 rows=100 loops=1)
  ->  Index Scan using idx_orders_status on orders
        Filter: (customer_id = 'C10293')
        Rows Removed by Filter: 482113
```

这个计划里，过滤掉了四十多万行。索引在，条件没吃上，扫描照样大。工具会把这条语句标红，但不会告诉你改不改索引。要不要改，得看这张表的读写比例。先看估算行数和实际行数差多少。差得远，统计信息多半过期了。再看共享读和临时文件，磁盘是不是在扛。这两眼，比看总耗时有用。

金仓AI数据库的能力，落在KES里。诊断这条线，先讲透。智能优化器会给执行路径建议。全诊断把采集和分析串在一条链路里。SQL映射应急能先稳住语句，不改应用。这些能力给的是证据和建议，签字还是留给人。所以诊断工具越自动，越要保留原始计划。建议可以覆盖，证据不能覆盖。

## 二、AI数据库会给建议，验证还得人做

工具给的方案，常常只差一个前提。前提没问清，方案越漂亮，坑越深。我见过一条建议：给订单状态建索引。状态只有几种值，选择性很低。建完查询不一定快，写入一定更慢。工具看得到字段分布，看不到下个月的活动。说到底，索引不是越多越好，写入路径会付账。这条账，工具不会替你算。

AI数据库在这层能做的是两件事。一是把候选方案列全，二是把依据摊开。剩下的事，得在影子库做。回放同一时段的流量，记录P95和扫描行数。对比变更前后的执行计划，别只看耗时。缓存会骗人，计划不会。还有，统计信息不新鲜，优化器也会算错。回放前，先确认统计信息的时间。

回放怎么做，我列了个清单。方向就一条：先有证据，再谈结论。

```text
变更前
1. 影子库回放同一时段流量，记录 P95 与扫描行数
2. 保存变更前执行计划、索引定义、统计信息时间
变更中
3. 只在只读副本先加索引，观察写入延迟和复制延迟
4. 生产变更放在业务低峰，限定执行窗口
变更后
5. 对比前后计划与 P95，异常则按脚本回滚
```

清单不复杂，难在每次都不省。省一次，后面要用一次事故补。

## 三、AI数据库能开口，权限不能松

AI助手一旦能连生产，问题就不在它会不会写错。问题是它拿什么身份写，出了事谁认。对话窗口可以很聪明，账号不能很宽松。给AI开的账号，建议按四条收。

- 只读账号，禁DDL和DML
- 只访问白名单schema
- 单次行数、语句超时都设上限
- 变更类操作走工单，不走对话

审计字段也要提前定。谁发起、哪条语句、碰了哪些对象。返回多少行、什么时间、结果给了谁。少一个字段，复盘就少一条证据。审计留存多久，按行业要求定。别等出了事再补字段，补不回来。

AI数据库的入口越方便，账号边界越要硬。权限收口不是不信任AI，是让每次事故都有主人。金仓AI数据库落地，绕不开多实例管理。KEMCC把多套实例和工具收在一个界面。跨环境统一纳管，入口少一层，权限就好收一层。KES的MCP Server已经在Gitee开源。AI工具接数据库的通道有了。通道开得再大，门禁也不能省。两样齐了，生产才敢开。

## 四、排查复盘：一条语句，三个答案

重载PL/SQL的排查，过程出奇地像。项目先报的是TPS上不去。先用KWR找热点，很快锁到一条语句。再用kbbadger看计划。关键字段上没有索引。补了一个索引，TPS还是不够。到这一步，很多人会收工。

很多人以为瓶颈就是索引，剩下的交给时间。团队接着用PLProfiler插桩。函数里的循环调用露了出来。改完循环，TPS才恢复。一条语句，三个答案：语句、计划、代码。前两个答案都对，但都不完整。工具先给出的答案，通常只是线索。线索要一层层往下追，追到能改的那一行。
![dba-three-answers.png](https://developer.qcloudimg.com/http-save/yehe-12655933/48831f3405c599c209fa2579aa620bc5.png)
这里值钱的不是索引，是加完索引后没停。停下来，结论就只剩“索引没用”。另一种情况更短。会话卡死，sys_stat_activity先发现异常。PLTrace看当前执行位置。SQL Monitor再看计划和等待。三步下来，卡在哪一段就清楚了。

这也是我看好把诊断做进数据库的原因。数据在库里，等待和执行也在库里。少一次导出，少一次对不上。诊断离数据越近，证据链越短。

## 五、决策框架：三条线，分清楚

我带团队时定过三条线，换库以后也照用。自动线管采集、告警聚类、热点排序、计划留痕。这些活重复、量大、出错代价小，交给工具。复核线管索引、参数、SQL改写和结构变更。工具出建议，人做回放。签字线管生产变更、权限授予和数据导出。工具留下证据，签字这件事还是人来。

三条线最怕混在一起。自动线一旦越界，出事时找不到责任人。签字线一旦失守，再好的工具也救不回来。这三条线，也是我判断一套AI数据库好不好用的标准。三条线要写进变更制度，不能只停在口头。口头约定，换个人就散了。自动线先跑三个月，再谈扩大范围。

![dba-three-lines.png](https://developer.qcloudimg.com/http-save/yehe-12655933/c32d275d6234360ea11d8603dae22de6.png)

## 六、避坑清单：AI数据库上生产前，先看三个坑

只看热点榜排头的那条语句。榜单按总耗时排，凌晨批处理很容易排前面。用户有感的是白天那条，不是它。排榜之前，先按时段分一刀。把建议当结论，跳过回放。索引、参数、改写，任何一项都要比前后计划。没有回放记录，就别在生产上试。测试库过了，不代表生产过了。

验证只验SQL，不验环境日历。有一年双十一前，我把批量任务从2点挪到4点。测试库跑通了，生产4点正好撞上备份。IO打满，第二天报表延迟到上午。后来我加了一项检查，变更窗口避开备份和统计任务。这个坑不在SQL里，在日历里。

## 七、回到那个问题：DBA还剩下什么

回到老同事的问题，AI数据库来了，DBA还剩下什么？我的答案是三件事：判断、验证、签字。这三件事不酷，也不容易写进PPT。但生产环境只认这三件。10月30日是电科金仓2026产品发布会，也是金仓数据库开发者大会。主题是「Hello，AI数据库」。会上提出的主张是“AI数据库用金仓”。我的理解是，AI能力要长在数据库里。

数据、诊断、权限、审计，不用搬来搬去。金仓AI数据库这条路线，也在这个方向上。KES把多模、优化器、全诊断放在一个引擎里。KEMCC把多套实例收在一个界面。MCP Server开源，外部AI工具能接进来。对从Oracle过来的团队，多语法兼容能少改一层SQL。但迁移上线前，计划和数据还得对一遍。能力边界也要说清楚。

工具越强，越要把验证和签字留在人这边。重复劳动交给工具。签字那道门，人得自己守。一套AI数据库，最后拼的是能不能被信任。这套组合不花哨，胜在能收口。诊断、权限、审计，不用各搭一套。

你们团队现在敢让AI助手连生产库吗？卡在权限、验证，还是没人愿意签字？评论区说说，我把那份回放清单整理出来。

我是路远。数据库这事儿，生产环境说了算。

上周二晚上，一个老同事给我打电话。他做了十二年运维，最近在学AI工具。他问我，AI数据库都能看执行计划了，这行还剩下什么？他问的其实不是工具，是自己的位置。

AI数据库诊断怎么落地？从语句热点到验证清单的5步排查

从一场压测事故和一条重载SQL的排查过程出发，拆解AI数据库能接走DBA哪些活、哪些活必须留在人手里，并给出一套诊断、验证、签字的决策框架。

数据库

人工智能

运维

AI数据库负责诊断、发现异常、生成建议，DBA掌握判断、验证和签字权。工具接管重复劳动，人在证据基础上做决策。KWR/PLTrace等工具提供证据，影子库回放验证方案，权限收口保障安全。生产环境里，AI和DBA按自动线、复核线、签字线分工协作，各司其职。

代码解释

让每一个 Agent，都跑在云上

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

AI数据库诊断怎么落地？从语句热点到验证清单的5步排查-腾讯云开发者社区-腾讯云

AI数据库诊断怎么落地？从语句热点到验证清单的5步排查

AI数据库诊断怎么落地？从语句热点到验证清单的5步排查

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐