别光盯着 Navicat 了，聊个天就把 SQL 写了，这个 AI 数据库工具杀疯了！

阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Fight/sqlchat-ai-database-tool/ 「芋道源码」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

在 GitHub Trending 上刷到 SQL Chat，5.8K Star，MIT 协议，Bytebase 那帮人做的。名字太直白，我一开始以为是蹭热度的玩具，结果装完连上 MySQL 聊了几句，Navicat 就被我最小化了。

把客户端做成聊天框，差别在哪

SQL Chat 首屏

它不是 Navicat 不行，是那套操作逻辑确实该换换了。传统客户端让你在「工具怎么用」上花掉太多注意力，而这件事恰恰最没必要动脑。

更烦的是注意力切换的损耗。看表结构是一套动作，写 SQL 是另一套，验证结果又是第三套，每换一次都要重新把上下文捡回来。聊天的形态把这些动作串在同一条线上了。

产品整体形态

SQL Chat 把人机接口换成了聊天框。它是 Bytebase 团队做的，用 Next.js 写，简单说就是一个能聊天的数据库客户端，2023 年 3 月建的库，现在五千八百多 Star。支持的数据库有 MySQL、PostgreSQL、MSSQL、TiDB Cloud 和 OceanBase。

一句话到一张结果表

打开之后，左边是数据库连接列表和 Schema 树，右边是对话窗口。

对话里生成的 SQL 与执行结果

我输了一句「每个部门工资最高的前 10 名员工」。它回了一段带语法高亮的 SQL，下面还有人话解释，告诉我这条语句 JOIN 了哪些表、WHERE 条件过滤了什么，再往下是一个执行按钮，点一下直接出结果表格。

整个过程我没有碰键盘写一行 SQL。它生成的 JOIN 比我手写的干净，子查询嵌套的位置也合理，执行计划里索引都用上了，没有全表扫描。

结果以表格展示，支持分页。我那张员工表 802 行，查询结果 10 条一页，翻页响应很快。还有个细节挺贴心，它把 SQL 和结果放在同一个对话气泡里，往上翻能看到每条查询的上下文。传统客户端的查询历史是一堆孤零零的 SQL 语句。这里的历史带着我当初的原始问题，回过头看要直观得多。

它怎么知道你的表结构

Schema 树与字段

连上数据库后，它会自动拉取 Schema 信息，左边面板能看到所有表、字段和索引。这些信息会被塞进发给模型的 Prompt，所以它知道你的表结构，不会瞎猜字段名。

从截图能看到，它把 employee、dept_emp、department、salary 四张表的关系理得很清楚，JOIN 条件和 WHERE 过滤都没出错。这块的 Prompt 组装确实下了功夫。

数据到底出去了多少

这一点得单独说，因为很多 AI 数据库工具让人不放心，你不知道自己的数据有没有被送到第三方。工具越方便，这个问题越值得先问清楚。

SQL Chat 的边界是这样的。连接配置存在浏览器本地，清缓存就没了。真正发给模型的只有 Schema 结构，表里的数据不走模型的接口。

如果用在线版，对话记录会被匿名保存，这也是它和自托管最大的差别。不放心的话可以自托管，API Key 和服务器都是自己的。

我比较满意的是它把哪些数据出去了、哪些没出去说清楚了，而不是含糊其辞。对要接生产库的人来说，这层说明比功能多寡重要。

三种跑法，五分钟能上手

创建连接时可选数据库类型

最省事的是在线版。打开官网，填上自己的模型 API Key，然后添加一个数据库连接，五分钟就能跑起来。

这里有个前提容易踩坑。如果数据库开了 IP 白名单，需要放行 0.0.0.0，因为在线版托管在 Vercel 上，IP 是动态的。我一开始没注意，连本地 MySQL 连了半天连不上。

想要数据完全不出门就用 Docker。

docker run --name sqlchat --platform linux/amd64 \
  --env NEXTAUTH_SECRET="$(openssl rand -hex 5)" \
  --env OPENAI_API_KEY=sk-xxxxxxxx \
  -p 3000:3000 --hostname localhost sqlchat/sqlchat

跑起来访问 http://localhost:3000。NEXTAUTH_SECRET 传任意字符串就行，不传 next-auth 会报错。

这里还有第二个坑。如果你连的是本机数据库，host 要填 host.docker.internal 而不是 localhost，因为容器里的 localhost 指向容器自己，不是宿主机。我一开始填 localhost 死活连不上，翻 Issue 才找到原因。

想改代码的话就拉源码，两条命令起步。

cp .env.example .env    # 把 API Key 填进 .env
pnpm i && pnpm dev

项目基于 Next.js，结构挺清爽。核心逻辑在 src/store/conversation.ts 附近，Prompt 组装和 Schema 注入都在那儿，改起来不费劲。

如果你不想把请求发到 OpenAI，README 里还有个 OPENAI_API_ENDPOINT 变量，默认指向 OpenAI 官方地址，改一改就能接到 Ollama 这类自建端点上。

它能替掉什么，替不掉什么

多库连接界面

Docker 连接设置

用了几天，我的结论是它替代不了 Navicat 的全部，但在快速探查数据这个场景特别顺手。所谓探查，就是我大概知道要什么、但不清楚具体在哪张表哪一列的那种查询。

以前的工作流是打开客户端、找表、看字段、开编辑器、写 SQL、执行、发现错了再改。这个循环里注意力一直在工具操作和业务逻辑之间来回切，每次切换都有损耗。它把中间步骤压缩掉了，我只需要描述要什么，SQL 和结果一起给我，注意力留在业务问题上。

局限也清楚。复杂存储过程、性能调优、DDL 变更这些场景，它替代不了专业工具，这些活仍然需要能看到执行计划、能逐步调优的专业界面。日常的数据探查、报表取数、业务验证，效率明显更高。

有一点要提前知道，这个项目的提交节奏慢下来了，仓库最近一次提交停在今年四月。社区之前贡献过 TiDB 和 OceanBase 的支持，东西本身是能用的，但别指望功能一直在快速迭代。

sqlchat/sqlchat 仓库首页，Star 5.8k

如果你每天要花不少时间写 SQL，花十分钟装一个试试。它可能不会完全替代你现在的工具，但某些场景下，你会想把 Navicat 最小化。

仓库在 https://github.com/sqlchat/sqlchat