让AI一边看代码一边查数据：我把调试bug的活甩给了它

平时开发和测试时，免不了要频繁查询或修改数据库。以往自己开个本地客户端跑几条SQL，顺手也就处理了。

但开始让AI Agent协助写代码后，卡点就出现了：AI能读懂上下文、修改代码甚至跑单元测试，却唯独看不见真实的数据库结构和数据。我必须一次次把DDL或schema提供给它，手动补充字段含义；遇到测试数据不对，还得自己切回终端写脚本补数据。来回折腾多了，既低效，又打断心流。

为了让AI Agent能够安全、直接地访问数据库，我对比过不少方案，最终选用了DBHub。它作为一个常驻服务，将数据库连接统一管理起来，让手头的各种AI工具都能从同一个入口调用。

DBHub是什么

DBHub是Bytebase开源的一款数据库MCP（Model Context Protocol）服务器。在Claude Code的官方文档中，连接PostgreSQL的官方示例推荐的正是它。

现在很多AI编码工具都通过MCP协议扩展外部能力。社区里针对数据库的MCP Server不少，但大多只支持单一数据库类型，且生命周期通常绑定在某个具体的编辑器或客户端进程上。

DBHub的不同之处在于：它是一个常驻运行的 HTTP 服务。通过Docker启动后，只要支持MCP的工具都能连上来。它原生支持PostgreSQL、MySQL、MariaDB、SQL Server、Oracle和SQLite，并且允许在一份配置中挂载多个不同的数据库实例。

简单来说，过去是每个工具各配各的数据库连接，现在变成了所有AI工具统一走DBHub。

我为什么选择它

让AI连接数据库并不只有这一种方式，但把零散的本地进程换成DBHub，主要出于以下几点考虑：

• 一份配置，多处复用：我平时会交叉使用多种AI工具（例如Codex、OpenCode、Qoder、Antigravity等）。以往每个工具都要重复配一遍连接信息，凭证分散且难维护；现在所有工具只需指向同一个DBHub地址，数据库连接集中管理。
• 增减数据库无需改动工具端：当需要新增一个业务库时，只需在DBHub的配置文件中追加一段 [[sources]]，重启容器即可生效，各个AI工具端无需做任何调整。
• 细粒度的只读保护：开启readonly = true后，AI只能执行查询类语句（如SELECT、SHOW、DESCRIBE），任何修改数据的操作（如 INSERT、UPDATE、DELETE、DROP）都会在服务端被直接拦截。测试环境若需要生成数据，可以按库单独开放写权限；而生产环境始终保持只读。
• 自带 Web 控制台：容器内置了一个轻量网页控制台，平时临时查数或调试SQL，在浏览器里就能直接跑，不必额外安装繁重的桌面客户端。
• 敏感凭证解耦：数据库账号密码统一抽离在.env文件中，配置文件仅通过变量引用，避免了凭据随配置误提交的风险。

部署与配置

通过Docker Compose部署最为轻量，准备docker-compose.yml、dbhub.toml和.env三个文件即可完成拉起。

1. 编写 docker-compose.yml

services:
  dbhub:
    image: bytebase/dbhub:1.5.0
    restart: unless-stopped
    init: true
    ports:
      - "127.0.0.1:8100:8080" # 仅绑定本机回环地址，避免向局域网暴露
    volumes:
      - ./:/config
    env_file:
      - .env
    command:
      - "--transport"
      - "http"
      - "--host"
      - "0.0.0.0"
      - "--port"
      - "8080"
      - "--config"
      - "/config/dbhub.toml"

提示：如果数据库运行在你的宿主机上，连接地址可直接使用 host.docker.internal。这是macOS和Windows下Docker Desktop的内置支持；若在Linux环境下，需在服务的配置中增加一行 extra_hosts: ["host.docker.internal:host-gateway"]。

2. 编写dbhub.toml

这里以PostgreSQL为例定义数据源与工具行为：

[[sources]]
id = "pg"
type = "postgres"
host = "host.docker.internal"
port = 5432
database = "postgres"
user = "postgres"
password = "${PG_PASSWORD}" # 引用环境变量

[[tools]]
name = "execute_sql"
source = "pg"
readonly = true             # 生产/排查推荐设为true；测试写入时按需开启
max_rows = 1000

3. 配置凭据并启动

在同级目录下创建.env文件，写入密码并调整权限：

echo "PG_PASSWORD=你的真实密码" > .env
chmod 600 .env

检查端口未被占用后，一键启动容器：

lsof -i :8100
docker compose up -d
curl <http://127.0.0.1:8100/healthz>

终端返回OK，即表示服务已正常就绪。

接入AI工具并验证

无论你使用哪款支持MCP的客户端，连接填写的都是同一个服务端点：

<http://localhost:8100/mcp>

各个工具的配置载体略有差异（例如有的支持在界面添加，有的使用JSON或TOML配置文件）。接入完成后，建议让AI依次执行两步验证：

1. 列出当前挂载的MCP工具，确认能识别到execute_sql等方法；
2. 执行一条基础验证语句：
   • PostgreSQL：SELECT current_database();
   • MySQL / MariaDB：SELECT DATABASE();

只要能成功返回当前数据库名称，就说明整条链路已经真正打通。

我主要用它来做什么

接入数据库之后，我和AI协同的许多环节省去了繁琐的人工介入：

1. 让AI自主阅读表结构

遇到涉及数据库的代码任务，不再需要手动提取DDL贴给AI，直接给一条指令：

“先查看当前数据库的核心表结构，再帮我编写对应的统计逻辑。”

AI能直接感知真实的表名、字段名和关联约束，编写出的SQL准确率大幅提升。

2. 自然语言直查数据

排查逻辑或核对逻辑时，可以直接提问：

“查询上个月未完成支付的订单总数及主要分布状态。”

AI自己生成查询、执行并总结结论，免去了我在编辑器、终端和客户端之间来回复制的开销。

3. 自动化生成测试数据

在开发测试阶段，可以将测试库临时开放写权限。当缺乏真实测试用例时，让AI根据业务实体与字段约束，直接生成成套且合规的模拟数据，覆盖率往往比手工构造更全面。

4. 源码与实际数据联合排查

有些线上或联调问题，仅看代码逻辑并没有破绽，症结往往在于某行特殊数据的边界状态。当AI能够一边阅读源码、一边查询现场数据时，定位隐蔽缺陷的速度明显变快。

工作流的实际变化

回看接入DBHub之前，AI编程工具虽然能写代码、改报错，但一碰到数据库就成了“盲盒猜谜”，我不得不充当人肉的数据搬运工与传话筒。

引入独立的DBHub后，最直观的改变是工作重心的转移：

• 容错更具闭环性：SQL 执行遇阻时，AI可以自己查表、修正类型并重新尝试；
• 环境完全解耦：数据库能力不再与具体某一款开发工具强绑定，更换AI工具时无需重复搬迁凭证；
• 职责更纯粹：从前频繁在“复制schema”上耗时间，现在只需要聚焦在审查AI最终的SQL逻辑与输出结果上。

实用避坑与安全建议

实际使用过程中，有几个细节需要留心：

1. 类型限制：目前DBHub主要面向常见关系型数据库，对Redis、MongoDB 等NoSQL暂不支持。
2. 警惕写权限风险：在开启写权限的情况下，AI具备执行危险指令（如DROP TABLE）的能力。建议始终遵循最小权限原则：仅给测试库开写权限，生产库强制保持readonly，且配置的数据库账号本身也只授予必要权限。
3. 改配后建议重启：虽然服务理论上支持部分热配置，但在使用Docker部署时，直接执行docker compose restart重启容器最为可靠，通常只需几秒钟。
4. 会话缓存刷新：部分AI客户端会在新会话启动时才拉取一次MCP工具列表。如果在运行途中增改了数据源，建议新建一个会话窗口进行测试。
5. 网络边界控制：DBHub 默认不设内建身份鉴权，部署时切记仅绑定127.0.0.1，切勿裸露在公网或开放局域网；如有跨机器访问需求，务必通过启动参数配置-auth-token。

如果你也经常在终端、数据库客户端与AI之间来回粘贴schema和结果，不妨在本地搭建一个DBHub试试。花费不到半小时，就能让AI真正打通代码与数据之间的断层。

你在使用AI处理数据库任务时有什么心得或踩过的坑？欢迎与我交流。