DBA 代理不记得昨天是谁写的慢查询

先说结论：方向对，但「全天候 DBA 助手」这顶帽子，它戴不住。这玩意更像一个态度很好的实习生——什么活都抢着干，唯独记不住昨天在你库里捅娄子的那条 SQL 长什么样。

凌晨三点被慢查询告警吵醒，你第一件事一定是打开它的界面：昨晚那条搞垮主库的查询，全文给我调出来看看。它拿得出手的，只有 pg_stat_statements 里一条按指纹聚类的聚合记录。

官方说：慢查询分析数据来自 pg_stat_statements 或 MySQL 慢日志，按指纹对查询聚类、排序、推荐。

我盯着这条看了半天，怎么想怎么不对味。你管这叫「推荐」？从 pg_stat_statements 里拿到的只有归一化模板、平均耗时、调用次数、总耗时占比。这堆统计数字够一个监控面板用了，但够一个 DBA 定位问题吗？

半夜那个场景，你要回答的是：这条慢查询哪来的？哪个业务方、哪个页面、哪个定时任务？今天跟昨天的形态差在哪？

指纹聚类给你的是平均脸。慢查询诊断从来不是认脸，是验指纹。

我把连接池里最慢的那条真实查询喂进去，等它多步骤推理跑完，顺手翻了一眼它引用的数据源——干净的聚类表，规范的排序，每一条都长得跟旁边的兄弟差不多。

queryid: 1234567890abcdef
calls: 107
mean_exec_time: 1842.33ms
rows: 4872

字段没问题，数字也没问题——可这条查询的实际文本呢？没了，只留一个归一化模板。

更妙的是官方页面那个示例：「加载业务上下文、解析 schema、起草并验证 SQL，每个步骤都可被检查」。看起来真透明。可我要的是事件本身的完整现场，不是流程演示。一个连异常查询原始文本都调不出来的值班员，怎么全天候？

你可能会说我抬杠：监控工具本来就该看聚合，谁天天翻原始文本？问题是它对自己的定位不是监控，是「全天候 DBA 助手」。它要做的是排查、干预、替人做判断。把「这一步可被检查」当亮点写在首页上，本身就是心虚的证据——真能理直气壮拿出完整依据的，根本不需要强调自己哪一步能被用户翻出来核对。

有一说一，它那套安全姿势摆得确实体面：只读副本、只读凭据、VPC 对等连接、数据不离开你的基础设施，比不少号称「企业级」的商业工具漂亮多了。冲着这条，我愿意多给它几分钟。但权限模型再完整，也补不上诊断链路最后一环的缺失——指纹数据告诉你「它慢」，不告诉你「它是谁」。

这钱花得冤不冤？看你拿它干嘛。当 BI 面板和权限管理用，值；当应急预案的入口，趁早把「DBA 助手」划掉，改成「DBA 实习生」。这问题不是不能修——让代理在诊断路径上主动留一份原始查询文本，随每次慢查询报告一起存档，不算多难的事。可惜按当前版本的状态，官方对这件事的回答是：未知。

哪天它能把「昨天那条查询是谁发的」答出个所以然，我再把「全天候」三个字还给它的宣传语。