数据库慢查询总在出问题后才被发现？RDST 用本地 Agent 持续整理优化计划
数据库性能排查经常始于用户投诉：先找出变慢的 SQL，再看执行计划、索引和数据库配置，最后才尝试修复。问题在于，查询负载会随数据量和业务变化；一次批量导入或索引调整，就可能让原本正常的路径成为新的瓶颈。Readyset 开源的 RDST（RDST Agent）尝试把这段流程前移：在本机持续读取 PostgreSQL 或 MySQL 的查询统计，形成一份按影响排序的优化建议。
它不是数据库代理，也不要求改应用连接路径。项目 README 说明，PostgreSQL 侧读取 pg_stat_statements，MySQL 侧读取 performance_schema，默认每分钟观察查询表现；对值得关注的查询，再结合 EXPLAIN、执行计划和 schema 分析潜在原因。建议可能涉及新增或删除索引、调整设置、改写查询或 vacuum。每项建议附有影响说明、实施步骤和适用时的回滚 SQL，方便工程师审查，而不是只给一个“慢查询”告警。
先让它只读观察
RDST 的桌面应用可连接数据库并启动 Agent。官方文档建议先配置只读数据库用户；工具直接连接数据库，不需要在应用与数据库之间插入代理，也不要求在应用代码里埋点。持续监控由桌面应用负责；CLI 文档将命令行定位为单次检查、脚本和 CI，因此不能把 rdst top 误解为常驻监控或 Inbox 告警。
命令行版本可通过官方安装脚本安装（macOS/Linux）：
curl -fsSL https://downloads.readyset.io/packages/rdst-cli/install.sh | sh rdst version rdst init rdst top --target mydb rdst analyze -q "SELECT * FROM users WHERE active = true" --target mydb
rdst init 用于配置数据库目标；rdst top 在终端检查较慢的查询；rdst analyze 对单条 SQL 做执行计划分析。CLI README 还列出 rdst audit 用于数据库健康审计，以及 rdst claude add 将 RDST 注册为 Claude Code 的 MCP server。官方安装器提供 macOS/Linux 构建；桌面版则覆盖 macOS、Windows 与 Linux。实际使用前应确认目标平台对应的安装说明与命令版本。
建议不是自动变更
在生产环境里，索引并非越多越好：它可能加速读取，却增加写入和维护成本。RDST 将建议整理成待处理计划，工程师可以从优先级较高的项目开始，阅读影响范围与 SQL，再决定是否在自己的环境执行。README 明确表示，RDST 不会直接对数据库执行更新或创建索引。它适合辅助诊断和制定行动顺序，不应被误解为自动修复系统或 DBA 的替代品。
部署前也要检查权限与数据流。项目会提醒可写账号改用只读账号；历史记录、报告和设置保存在本机。隐私文档说明，AI 请求可能包含规范化 SQL、schema、索引和耗时证据；深度分析则可能在本地数据库上以真实值运行查询，且文档会标注数据来源。若不希望自动分析执行带真实值的查询，可关闭 Deep analysis。文档还说明不同功能请求可能发往 Readyset 的模型服务或用户配置的提供方，因此应按数据分类与组织政策审核请求内容和目标端点，再决定是否接入生产环境。
用反馈验证每一条建议
一个务实的试点流程是先接入低风险的测试库或只读生产副本，观察一段时间后选取一条高影响查询，人工核对建议及其回滚方法；在受控窗口执行变更，再比较查询表现，确认收益没有以写入性能或其他查询为代价。RDST README 描述的工作流也包括将变更标记为完成，并由 Agent 检查它是否有帮助。
RDST 的价值不在于“AI 会替你改数据库”，而在于把分散的统计、执行计划分析和建议汇总成持续更新的清单。对于查询种类多、回归难以及时察觉的 PostgreSQL/MySQL 项目，这种本地观察加人工审批的模式值得评估；若团队需要自动执行修复、强一致的实时告警或额外数据库类型，则应先确认项目是否覆盖这些需求，而不要从“Agent”一词推断它具备相应能力。
相关链接