数据库自治诊断到底在自动化什么
博客园上有开发者开源过一个基于 .NET 的自托管数据库性能诊断平台：给它几个实例的连接信息，它持续采集性能数据，把 DBA 的日常工作搬进 Web 控制台，覆盖 SQL Server、MySQL 与 PostgreSQL。我们读它不是因为功能多，而是因为它把这类平台的核心问题说清楚了——自治诊断自动化的对象不是判断，是留痕。
一、它在自动化哪一段
减少数据量、分库分表、加缓存、一主多从，这些事前手段靠的是人的经验，工具帮不上太多。需要工具的是事后。
偶发飙高最磨人——一刹那的抖动，等你登上去看，现场已经没了，什么证据都不剩。隐患不理，它会一直长大，某天突然爆发，整个系统缓慢与阻塞，这时想定位只能凭记忆去猜：之前是不是发过版，那天是不是跑了张大报表。根源在数据源本身：这些引擎的动态管理视图给出的是内存里的累计值，重启就清零。不留痕就没有历史，没有历史就没有趋势。
所以我们划了一条硬线：这类工具可以自动采集、留痕、关联、生成候选结论；它不应该自动下判断，更不能自动执行变更。
二、采什么：要证据链，不是指标墙
指标墙最没用：一堆曲线摆在那里，看完仍不知道该改哪条 SQL。我们认可的最低配置是四组证据。
- 按会话而非按实例的等待归因。 实例级聚合的等待统计是从启动累积到现在的值，谁也说不清这一分钟是谁在等。那位开发者改成按会话采样正在执行的请求，把等待桶化成 CPU、锁、IO、其他，再按平均活跃会话拆开负载。
- 执行计划的快照与变更事件。 计划变更必须带时刻，能和变慢对上；趋势图上叠加死锁、慢 SQL、计划变更的竖线，比再多一张仪表板都有用。
- 累计值的差分与差分的边界。 每拍记快照、与上一拍相减才得到区间真实增量。麻烦全在边界：实例重启时累计值清零，差分会出现负的天文数字，这一拍不能落库只能重建基线；新指纹没有上一拍可差，要落全量；没重启却差出负数，说明计划被驱逐出缓存，应跳过并同步基线。边界不处理，趋势图上就会出现负值或莫名断崖。
- 指纹归一与噪音排除。 同形语句合并成模板要优先用引擎原生指纹。噪音更值得警惕：那个平台上线第一天，榜首语句的 CPU 占比 68%，就是监控自己的巡检语句。
事件类证据（死锁、锁等待链、超阈值的慢 SQL）要走独立留档，不受采样节奏限制，才兜得住偶发场景。判重不能用等值匹配：时间戳在采集端、落库列与参数化发送三处各舍入一次，叠起来能差出 1 到 2 毫秒。
最后是开销红线：只读内存里的元数据视图，不扫业务表、不产物理 IO、不对用户对象加锁；那个项目给出的常规开销是低于被监控实例 1% 的 CPU。诊断工具自己变成性能问题，是这类系统最大的讽刺。
三、阈值与规则引擎的老毛病
阈值这件事，多数团队的真实来源是拍脑袋。问题不在数值不准，而在跨实例不可迁移：一台只跑核心交易的小规格实例，和一台专门扛报表分析的实例，同一个耗时阈值意味着完全不同的事，几乎必然同时产生误报和漏报。
我们的顺序是先建基线再谈阈值：基线来自自采样差值与长区间历史，用分位而不是均值刻画分布，阈值随实例分组、按时段分层。在那之前，任何超过多少就告警的规则都只能当线索，不能当结论。
规则引擎的第二个局限是它只覆盖已经发生过的问题。缺索引、锁等待链过长、统计信息新鲜度差、无用索引（靠读写计数识别，附删除或禁用脚本）能写成规则；偶发飙高的成因常在规则之外。所以我们要求系统诚实：没有对等数据源的功能宁可自动隐藏或降级，也不要硬造数据。
四、大模型能补哪一段，补不了哪一段
能补的第一段是把 DBA 的排查话术结构化。 资深工程师的思路是一套隐性流程：先看负载被拆成哪类资源打满，再看这个时间窗有没有事件，再下钻到具体语句。这套话术过去只存在于人脑和零散的运维文档里，模型的价值是把它变成可以追问、可以按症状展开的排查路径。
能补的第二段是根据症状生成候选假设。 输入某类等待上活跃会话堆积、同时段有发布，模型能列出若干可能成因，并把证据与反例对应起来，把人从零开始猜挪到验证候选。
边界上我们很认同那个项目的做法：内置只读的 MCP 服务，把指标、慢 SQL、死锁、阻塞、索引证据以只读工具交给 agent，配了 ApiKey 才开启、默认关闭；agent 全程不直连数据库，它拿到的每条证据都来自平台已经采集落库的结果。
补不了的第一段是不能替它执行变更。 建索引、改语句、调参数、杀会话，后果不可逆或有连锁影响。让 AI 碰生产库需要的不是更聪明的模型，而是明确的权限边界：证据交给 agent，写操作留在人身上。
补不了的第二段是没有基线时判断不了异常。 一个孤立数字没有含义。差分需要上一拍，重启后要重建基线，异常判断的前提是历史。系统刚上线、业务模式换了，这段时间模型给出的任何是否异常的结论都不可信。
五、给中小客户的分层落地方案
不是每家公司的数据库都上了云监控，也不是每家都配得起专职 DBA，多数时候数据库出状况都是开发自己顶上去。我们给这类客户的方案分三层，区别不是功能多少，而是权限和责任。
| 层级 | 交付内容 | 准入条件 | 风险红线 |
|---|---|---|---|
| L1 只读巡检出报告 | 持续采集与留痕、性能洞察与趋势、慢 SQL 与死锁阻塞归档、索引使用率清单、巡检报告 | 只读账号即可；采集开销实测低于约定上限 | 不写业务表、不对用户对象加锁、历史一律写平台库；报告只描述现象与证据，不下必须怎么改的结论 |
| L2 索引与 SQL 改写建议 | 缺失索引建议与建索引脚本、无用索引禁用脚本、高频语句改写方向、执行计划前后对比 | L1 稳定运行并建立基线；有能看懂计划的开发责任人；脚本经评审后由人执行 | 脚本只生成不执行；每条建议标注依据；不许回改历史让指标好看 |
| L3 自动执行变更 | 限窗口的索引创建与删除、参数调整、会话终止，带执行前快照与回滚 | 仅对可回滚、影响面单一的对象开放；必须有灰度批次、一键回退和完整审计；审批人与执行人不得同一人 | 涉及资金、权限、隐私、核心链路和数据删除的动作一律禁止自动执行；无基线期间禁止触发 |
最重要的门槛是能不能自证：L1 的开销可查累计 CPU 秒，L2 的建议必须回溯到具体证据，L3 的执行要留下审计与回滚路径。
六、我们的红线：默认只读，变更走人工审批
洹拓科技在云服务与 SaaS 运营上给客户定的规矩一直没变：诊断系统默认只读，任何变更必须经人工审批，AI 只出现在证据与候选假设这两端。理由很朴素——工具能给你的是现场，不是责任。什么算正确、哪些风险可以接受、出了问题谁负责，这三件事不能被外包给模型，也不能外包给一个阈值。
至于选不选某个具体平台，我们只看三件事：证据链是否完整，降级是否诚实，边界是否清楚。问得出来，选谁都能用；问不出来，换成任何标榜自治的产品，也只是把猜的过程包装得更好看一些。