AI 数据库运维验收笔记：采集、基线、变更

这份笔记只记一次值班：一份 AI 数据库分析报告，怎么从“看起来有道理”走到“可以签字”。我只留证据链、退回条件和一张复核单。

我是阿哲，八年数据库运维和优化，金融行业甲方出身，后来做独立顾问。我没参会，也没测试环境。下面这些场景是脱敏教学示例，用来讲验收方法，不是生产数据，也不代表任何产品的表现。

接报：先登记，不改库

报告是上午转来的，附件两份：一份结论页，一份图表。结论页写着“某时段 I/O 偏高，建议调整参数”，图表只有一条曲线，没有时间轴说明。

我先登记：报告来源、对应库、时间段、建议动作、附件清单。登记完，回一句“收到，先复核”，不转给执行人。

值班记录
现象：结论页有建议，附件没有采集窗口和原始样本，图表也缺时间轴。
动作：把报告编号和缺口写进值班本，要求出具人补采集页。
结论：材料不齐，退回补充；今天不动参数。

接报看着慢，其实省事。报告进了执行群，很多人默认它已过审；等签字的人发现问题，窗口可能已经开了。

取证：证据链五段，断一段就退回

一份能复盘的报告，证据链至少五段：采集配置、原始样本、基线对比、结论、建议。我按段对，不按页数对。页数多不代表证据多，图表漂亮也不代表样本够。

环节	要留的证据	断链表现	退回/不签
采集配置	账号、权限、视图、窗口、频率	只写“系统负载高”	要权限与视图清单，给不出就退回
原始样本	会话、锁、等待事件、指标快照	只有结论，没有样本	要证据编号与导出，导不出就退回
基线对比	业务日类型、历史区间、对比口径	只给当前值	要对比明细，给不出就不签
结论	根因、排除路径、不确定项	只给一个答案	要排除过程，没有就降为线索
建议	影响面、回滚、验证、签字	只写“建议优化”	退回变更评审，不进窗口

这张表不争论“准不准”，只看证据断在哪一段：断在采集，结论不用讨论；断在基线，“高”“低”没有意义；断在建议，不能进变更单。

值班记录
现象：报告说“锁等待严重”，原始样本里只有库级 CPU，没有等待事件。
动作：把该结论标为“未验证”，要求补对应时段的等待事件视图。
结论：锁等待部分退回，不能作为加索引的依据。

采集开销也要写进证据链。开在高峰的采集可能把库拖慢；没有暂停开关，出问题只能停整个任务。通过标准是“能控制着采”。

比对：把业务日历摊开

没有基线，“高”这个字没有意义。报告写“某时段 CPU 使用率偏高”，我会追问：这个库平时多少？跑批那半小时多少？偏高持续了多久？跟昨天比，还是跟上周同一天比？

基线要按业务日类型分开。普通日、跑批日、月末，负载形状不一样；只有按小时曲线、没有业务日历，跑批日就可能天天被报成异常。

业务日类型	关注什么	通过	退回/不签
普通日	连接、等待、慢 SQL 的日常曲线	能对上上周同类型日	只有当前值，没有历史对比
跑批日	跑批窗口、批处理时长、锁等待	跑批时段有独立基线	拿普通日阈值套跑批日
月末	月末高峰、批量作业、空间增长	高峰有独立参照	月末和普通日混在一起
特殊日	连接峰值、写入峰值	单独标注，不混入普通日	不说明业务背景，直接判异常

通用模型不知道你几点跑批，也不知道你上周刚做完迁移。这些信息得从业务日历里来。

签字：回滚写在前面

报告给的是建议，不是变更单。加索引、改参数、重写 SQL，每一件都有副作用。我看变更部分，先找四样：影响面、回滚方案、验证方法、签字人。

变更类型	影响面要看什么	回滚怎么做	退回/不签
加索引	哪些 SQL、写入比例、磁盘与维护成本	删索引，确认执行计划回到原状	没算写入成本，不签
改参数	哪些会话、是否重启、生效范围	恢复原值，必要时重启	说不清生效范围，不签
重写 SQL	结果集、执行计划、依赖对象	保留旧语句，按版本切回	不做结果集核对，不签
删对象	依赖它的 SQL、作业、接口	先备份定义与数据，按顺序恢复	没有依赖清单，不签

回滚方案要能执行，不是一句“可回滚”。脚本在哪、谁执行、依赖什么权限、回滚需要多久、回滚后怎么确认恢复，都要写清楚。

值班记录
现象：建议在交易表加索引，影响面只写“提升查询”，没写写入比例和回滚。
动作：要求补写入比例、磁盘增量、删索引的回滚步骤和验证 SQL。
结论：四样缺三样，退回；补齐后再进变更评审。

加索引之前，我还会看两个数：这条 SQL 跑多少次，这张表的写入比例多高。跑一次的全表扫描，和跑一万次的全表扫描，优先级不一样。工具可以把这两个数摆到我面前，但“要不要改”还是人签字。

退回：两类报告直接合上

退回条件一：证据对不上时间线。 报告说某时段异常，采集窗口却只覆盖另一个时段；或者结论提到锁等待，附件里没有等待事件样本。对不上，就不签。

退回条件二：建议没有可执行的回滚。 只写“有问题就回滚”，不写脚本、执行人、耗时和恢复确认。这样的建议进了窗口，出事只能现场想办法。

退回时写清楚缺哪一段、补什么。只写“不同意”，下一次还是同一份材料。

归档：链接归到“待验证”

笔记最后，把群里那条发布会链接也归了档。10 月 30 日，金仓开了一场发布会，主角是一款 AI 数据库。公开材料里讲了三项“库内”能力：库内语义构建、库内计算推理、库内原生安全管控；相关主张可以理解为让数据尽量留在库内完成 AI 处理。发布会和随后的开发者大会还提到运维智能体、管控平台，但公开材料没有展开细节。

这条链接归到“待验证”，不写能力结论。它没有回答采集权限、跑批基线、变更签字这三件事。我也不替它回答。没有环境、没有执行记录，我不写“它能查得多准”；等有环境，按上面这张单子逐项对。

复核单：照着打勾

• 采集账号有权限清单，不是一句“只读”
• 采集窗口覆盖结论对应的时间段
• 采集开销有说明，有暂停开关
• 基线区分普通日、跑批日、月末
• 历史对比有区间、有口径、能导出
• 变更建议写了影响面
• 回滚脚本可执行，执行人明确
• 验证 SQL、指标、通过标准提前写好
• 变更单上有建议人、执行人、复核人

这张单子只看证据，换一套工具还能用。

值班结束：留给下次的规则

值班结束，我写一条规则：证据链断在哪一段，就从哪一段退回；不要跳到结论上争论。

AI 数据库不会让排查这件事消失。它只是把翻视图、写报告的时间省下来，把判断的时间留给人。三条都在，报告可以看；缺一条，报告就只是线索。