DeepSQL 实战：给 Postgres / MySQL 加一个只读的自托管 AI DBA，先把分析与执行分开
数据库团队想要的通常不是又一个会把自然语言翻成 SQL 的聊天框，而是一个能回答三个更棘手问题的助手：最近哪些负载在退化、业务口径到底怎样定义、某条建议是否值得真的执行。把 LLM 直接接到生产库会把这三个问题混成一个风险极高的动作：它既要猜测语义，又要构造查询，还可能在不合适的连接上运行。
DeepSQL 的思路是把 AI DBA 放在自托管环境中：它面向 Postgres 和 MySQL，安装程序会部署 agent、CLI 与 MCP server；数据库使用只读凭据，并建议连接 read replica 或 VPC 对等网络中的实例。它还把 schema、业务知识和慢查询来源放进同一工作流。对已经有 Claude、Codex 或 Cursor 的团队来说，MCP 的价值不在于“让 Agent 获得数据库万能权限”，而在于让 Agent 能在已有约束下请求可审计的数据库分析。
本文不把 DeepSQL 当作自动改库工具，而把它放在更稳妥的位置：只读诊断层 + 人工确认的变更闭环。这是比“把生产连接串交给 Agent”更适合日常工程协作的起点。
先界定它解决的边界
常规监控擅长告诉你 CPU、连接数和慢查询数量；但它未必能理解“活跃客户”“MRR”“有效订单”这类团队自己的业务语义。另一端的文本转 SQL 工具虽然能回答问题，却可能不知道某个宽表的读取代价、历史上出现过的相似负载，以及应当避开主库。
DeepSQL 首页展示的输入包含三类：数据库连接、以自然语言写下的公司知识、以及 pg_stat_statements 或 MySQL slow log 等慢查询来源。它会索引 schema、学习工作负载，并将相近 SQL 聚类为 fingerprints。这样，一个“过去七天哪些客户的数据写入速度最高”的问题不应只产生 SQL 文本，还应经过语义、schema、工作负载与执行计划几个步骤。
这里有一个必须保留的工程判断：产品页面展示的“节省 38% 数据库成本”是厂商的产品主张，不是对任何系统都成立的基准。团队应该把它当成需要自行验证的假设，先选一类昂贵且可回滚的负载做试点，而不是据此承诺节省目标。
部署前：把连接权限缩到最小
首页给出的安装命令如下。它是官方明确展示的安装入口；运行前应在测试 VPC、隔离主机或容器环境中审阅安装脚本与网络出口策略，而不是在生产跳板机上直接执行。
curl -fsSL https://install.deepsql.ai/install.sh | bash
真正决定安全边界的不是安装命令，而是数据库账号和网络路径。官方页面建议使用 read replica、VPC-peered 的连接以及 read-only credentials。下面是把页面中展示的连接字段整理成的权限设计清单，并非可直接复制的 DeepSQL 配置文件：
host = analytics-read-replica.internal role = deepsql_ro ssl = require 权限 = 仅 SELECT；不授予 DDL、写入、用户管理权限 网络 = 仅允许 DeepSQL 所在子网到副本的数据库端口
不要因为账号叫“只读”就跳过验证。试点前应由 DBA 用该账号分别检查：能否读取必要 schema、能否访问统计视图、是否无法 INSERT / UPDATE / DELETE、是否无法执行 DDL。若业务库没有副本，优先新建一个受控的分析副本；不能为了让助手方便访问而把主库写权限交出去。
将业务口径作为受控输入，而不是提示词附件
AI 对数据库最常见的错误不是 SQL 语法错，而是语义错。例如“收入”可能是已支付订单、已确认发票，也可能是订阅 MRR；“活跃客户”也常带有时间窗口和状态条件。DeepSQL 的页面把这类定义称为 company knowledge，并以类似 MRR = SUM(subscription.mrr)、WHERE status = 'active' 的规则说明其用途。
实操时，建议把这些规则当作版本化资产维护：
- 每条定义写清表、字段、过滤条件、时间边界和负责人；
- 为高风险指标附上至少一个人工核对过的 SQL 结果；
- 指标变更走和应用代码相同的评审流程；
- 不确定时让工具返回“缺少口径”，不要让模型自行补全。
这样做的好处是，Agent 不是“记住了某个聊天中的解释”，而是被提供了一组可审查的上下文。对财务、增长和合规指标，这个差别尤其重要。
一次诊断怎样走完：从慢查询到人工批准的变更
假设产品报表在高峰期变慢。比较可靠的闭环不是让 AI 立即创建索引，而是分成五步。
第一步，定位候选。 将慢查询日志或统计信息接入后，按频率、延迟、扫描量和资源消耗筛选。页面说明其可从 pg_stat_statements 或 MySQL slow log 获取来源；这两个来源解决的是“哪些语句值得先看”，而不是“该怎么改”。
第二步，复原语义。 查询涉及的指标必须先匹配已维护的业务规则。若问题是“订单增长”，先确认是创建时间、支付时间还是结算时间；没有明确答案就停止在分析阶段。
第三步，在副本上验证计划。 DeepSQL 的演示流程会解析 schema、参考既有 workload、起草查询并验证计划。对团队而言，关键产物应是可交给人复核的 SQL、EXPLAIN 输出、预期扫描范围与风险说明，而不是一句“已优化”。
第四步，独立评估取舍。 新索引可能改善读延迟，也可能增加写放大、WAL、存储和维护成本；分区可能改善隔离，也可能增加查询与运维复杂度。DeepSQL 博客对索引、分区、BRIN 与查询成本有大量讨论，但产品建议不能替代你自己的压测。把候选 SQL 在接近生产的数据量上做基线比较，记录 p50/p95、读取量和写入影响。
第五步，人工批准并回滚可用。 真正的 DDL 或参数变更继续走迁移、评审、发布窗口和回滚方案。AI 助手可以缩短诊断时间；执行权限仍应留在既有变更管理体系中。
如何把 MCP 接入编码 Agent，而不把它变成旁路
主页还给出远程 MCP / CLI 客户端的 npm 安装方式：
npm install -g @deepsql/mcp@latest
它说明 Claude、Codex 与 Cursor 可通过 MCP 或 CLI 连接到 DeepSQL 实例，但没有在公开主页列出完整的 MCP 配置 schema、工具名或每个子命令。因此，接入时不要凭产品名猜测 JSON 字段或工具名称。应从产品当前文档或安装后本地帮助中复制实际配置，并在测试项目中验证以下四件事：
- Agent 只能连接到预设的只读实例；
- 查询记录能关联到用户、会话与数据库目标；
- 大结果集、全表扫描和敏感表有明确的拒绝或审批策略；
- Agent 的回答包含 SQL、数据来源、时间范围与不确定性，而不只给自然语言结论。
尤其要避免把“让编码 Agent 查询数据”理解为“让它随意查看所有数据”。生产数据中可能包含个人信息、密钥痕迹或商业敏感字段；数据库角色、行列权限、脱敏视图和审计日志仍是第一道控制面。
适合先试点的团队与不适合的场景
最适合试点的是：已有只读副本、慢查询统计、业务指标文档，但 DBA 或数据工程师经常被重复排障问题打断的团队。先选一个报表、一个服务或一个库，限定观察周期，比较“发现问题到提出可复核建议”的时间，而非直接比较模型回答是否流畅。
不适合直接上线的情况包括：没有可隔离的只读路径、业务口径本身无人维护、生产变更没有评审与回滚流程，或者希望 AI 自动修复所有慢查询。前两种会造成错误结论，后两种会把诊断能力误当成执行授权。
DeepSQL 值得关注的点，是它把 schema、负载、慢查询、业务知识和 Agent 接入放进同一条链路。但真正能让这条链路落地的，是团队是否坚持“副本优先、最小权限、语义可追溯、变更人工批准”四个原则。先把 AI DBA 限制成一名证据充分的只读分析员，之后再逐步扩大自动化范围，通常比一开始追求全自动更快也更安全。