RDST：一个本地 Agent，专门盯着 Postgres/MySQL 的查询退化
今天在 HN 上刷到一个挺对味的东西。RDST，一个跑在本机上的数据库 Agent，干的事就一件：盯着 PostgreSQL 和 MySQL 的查询，一旦性能退化立刻报警，还顺手把该加的索引、该改的写法都分析出来。
这事之所以让我停下来多看了两眼，是因为它在回答一个所有跑过生产库的人都绕不过去的问题：数据库故障为什么永远是被动挨打。
作者的原话，做 DBA 相关工作做了很多年，发现修数据库问题永远是被动的。一个无界查询悄悄膨胀，没人注意，整库可能在一夜之间就崩了。传统流程是 DBA 听到慢的投诉，然后手动翻 pg_stats、看哪些查询最慢、找缺哪个索引、再判断哪个索引反而拖慢了写入，最后吃力地去修。全是人肉排查，等发现问题时往往已经疼了一两天。
他举了个例子，某用户的结账页面从秒开到变成 11 秒，一晚上的事，代码一行没改。原因是 BI 团队往 order 表里灌了 4000 万行历史数据，Postgres 突然开始做全表扫描。日常操作带来意外后果，然后数据库就废了。
RDST 的解法是把这个「always-on 盯着的人」换成 Agent。它跑在本地 PC 上，只读连接 Postgres/MySQL，每分钟把每条查询跟它自己的历史性能比一次。每个昂贵查询会自动 EXPLAIN ANALYZED，剥掉 PII 之后发给美国的前沿或开源模型提供商，让模型分析缺什么索引、查询怎么写更好、并提供修复方案。然后一个叫 JEV 的分类模型决定要不要提醒，判断标准是「这是这条查询的正常表现吗」。查询性能的完整历史会保留好几年。它还会整体跟踪数据库健康，不只是坏查询，会推荐更多修复项。
再说几个细节。因为跑在本机，数据库凭据存在操作系统的 Keychain 里，RDST 自己不存；连接直达数据库，私有连接走跳板机或 SSH 隧道。这块数据怎么处理尤其是涉及 LLM 的部分，官方文档里有专门页。推理费用更是全免，团队就是想从跑生产库的人那里收反馈。
不过它有个边界，现在不会对数据库执行任何更新或建索引的操作。修不修、怎么修，决定权完全在你手里。自动模式在考虑中，但现阶段它只做「会分析的军师」，不做「自动动手的白衣骑士」。
HN 上第一个评论也很有意思，来自 Frone125：说几乎到了愿意让 Agent 直接动手建索引的程度，但还是没完全信任它到这个级别，不过很喜欢它给的建议，哪怕不会每条都建，至少它会检查哪些索引该删。这种心态很典型，AI 从「给建议的副驾」到「掌方向盘的司机」之间那道信任门槛，比技术门槛难跨多了。
对在生产上跑 Postgres/MySQL 的人，这算是个值得装下来自己跑跑的东西，反正推理免费，本机跑也只读。装不装你自己判断，但「查询退化」这个具体痛点，它确确实实踩中了。