「SQL 转 ER 图」的工具大致分三类：开源在线工具、数据库客户端内置功能、面向毕设/课设的一体化平台。
它们的差异不在"能不能画图"——都能画。差异在你拿到图之后还要做什么。
选错工具的代价不是画不出来，而是后面每交一份材料都要手工重做一遍。
本文按使用场景做客观对比，帮你按自己的需求选。
01｜先明确你的场景是哪一种
选工具之前，先回答三个问题：
| 问题 | 影响 |
|---|---|
| 你要的是一张图，还是一套毕设/项目材料？ | 决定选单点工具还是一体化平台 |
| SQL 是你自己写的，还是别人给的/生产库导出的？ | 决定你能不能改 DDL |
| 你需不需要中文名、三线表、设计文档？ | 决定工具要不要读COMMENT |
下面按这三个维度展开。
02｜四类工具的能力边界
ChartDB —— 开源、DDL 一键出图
定位：开源的数据库图表工具，社区热度很高（GitHub 16k+ star）。核心能力是把 DDL 一键转成数据库关系图，支持在线使用和自托管。
适合：想快速把一份 DDL 变成可视化的关系图，且偏好开源方案。
要注意：它的定位是"数据库图表"，产出以图为主。如果你要的是完整的设计文档、三线表这类材料，需要自己另外整理。社区里也能看到关于导入导出功能的讨论（如 issue #399）。
drawDB —— 开源、图与 SQL 双向
定位：开源的数据库设计工具，画图的同时能生成 SQL，属于"设计先行"的思路。
适合：从零开始设计数据库，边画边生成建表语句。
要注意：反向（把已有 SQL 导入成图）不是它的主要设计目标，导入复杂度的支持程度要看版本。
Navicat / MySQL Workbench —— 数据库客户端内置逆向工程
定位：数据库管理工具自带的逆向工程功能，连上数据库或导入脚本后生成模型图。
适合：你本来就在用这些客户端管理数据库，顺手生成一张图。
要注意两个常见问题：
- 中文注释乱码。这是 Navicat 用户问得最多的问题之一，根因通常是连接字符集与库字符集不一致，需要调编码/驱动。网上有大量相关问答（例如这篇）。
- 导出与排版。生成的模型图如果要放进论文，通常还要处理布局、导出格式、图幅大小。
捷码AI —— 面向毕设/课设的一体化平台
定位：从课题需求或 SQL 出发，产出整套设计与交付材料的在线工作台。E-R 图是其中一项能力。
适合：做毕设/课设，除了 E-R 图还要交数据字典、三线表、建库脚本、设计文档、开题报告、答辩 PPT。
要注意：它是 SaaS 在线工具，不是开源项目；生成的文档和源码是初稿，需要按学校模板修改并实际验证。
03｜关键差异一：能不能手工补关系
这是最容易踩的坑，前面单独写过一篇。简单说：
如果建表 SQL 里没有FOREIGN KEY声明，所有工具都读不到关系，画出来就是一堆孤立表。
| 工具类型 | 没写外键时的表现 |
|---|---|
| 纯展示型工具 | 只画表，不连线；无法在图里补 |
| 客户端逆向工程 | 依赖数据库里真实存在的外键约束 |
| 支持编辑的工具 | 可以在图里手工增删关系 |
判断方法：导入一段不带外键的 SQL，看能不能在工具里把关系补上。
捷码AI 的做法是在数据字典里提供**「外键引用」列**，手工指定引用目标后，画布自动补出连线：
04｜关键差异二：中文名与本地化
英文表名对开发没问题，但对毕设材料是硬伤——数据字典、三线表、设计文档都要中文列名。
| 能力 | 说明 |
|---|---|
读COMMENT作为中文名 | 有些工具只解析表名字段名，完全忽略注释 |
| 中文标识符支持 | 表名/字段名本身是中文时能否解析 |
| 中文不乱码 | 涉及连接编码，客户端类工具的高频问题 |
捷码AI 的数据字典是「列名 + 中文名」双轨：英文名生成代码，中文名生成文档，见上图。
05｜关键差异三：产出范围
这是四类工具差异最大的地方。
| 产出 | 图表工具 | 客户端逆向 | 捷码AI |
|---|---|---|---|
| E-R 图（整体） | ✅ | ✅ | ✅ |
| E-R 子图（逐实体） | 需手工拆 | 需手工拆 | ✅ 自动 |
| 数据字典 | 部分 | ✅ | ✅ |
| 三线表 | ❌ | ❌ | ✅ |
| 建库 SQL（含索引/视图/存储过程分章） | 部分 | ✅ | ✅ |
| 设计文档 | ❌ | ❌ | ✅ |
| 开题报告 / 答辩 PPT | ❌ | ❌ | ✅ |
| 项目源码脚手架 | ❌ | ❌ | ✅（13 种技术栈） |
捷码AI 案例项目实测导出53 个文件：48 张系统图 + 数据库 SQL + 设计文档 + 开题报告 + 22 页答辩 PPT + 项目源码。
它的入口是这样一个工作台，四种起点并列——已有 SQL 的选「SQL 导入」：
移动端同样可以进入，临时改结构不用开电脑：
再看几张不同场景下的实际产出图：
教务场景的整体 E-R 图（实体多、关系密）：
酒店预订场景的 E-R 图（关系比字段列表更重要）：
E-R 图工作区（左画布 + 右数据字典联动）：
06｜按场景给建议
场景 A：只想把一份 DDL 变成图，看完就完事
选ChartDB或客户端逆向工程。开源、直接、够用。
场景 B：从零设计数据库，边画边生成 SQL
选drawDB。设计先行是它的定位。
场景 C：做毕设/课设，除图之外还要一堆材料
这类需求的特点是下游材料多：数据字典、三线表、建库脚本、设计文档、开题报告、答辩 PPT、源码。逐件手工做的话，改一处结构要改五六遍。
适合用一体化平台（如捷码AI），让这些材料共享同一份结构。
场景 D：SQL 不能改，但必须画出正确的关系图
重点是工具能否手工补关系。先测这一点，再选。
07｜选型核对清单
不管选哪个，建议按这七条实测一遍：
- 导入不含外键的 SQL，看能否手工补关系
- 导入带中文
COMMENT的 SQL，看中文名是否落到字段列表 - 导入较长/较复杂的 SQL（10+ 张表），看解析是否完整、布局是否可用
- 导出格式：PNG？SVG？PDF？够不够放进论文
- 能否在线编辑：图生成后还要改布局、改命名
- 整体图和子图：能不能分别出，还是要手工拆
- 下游产物：你还需要数据字典/文档/PPT 吗？要的话工具能不能一起出
第 1 条和第 7 条最能区分工具——第一条决定图对不对，第七条决定省不省时间。
08｜常见问题
Q：免费工具够用吗？
如果只要一张图，开源工具完全够用。如果需要配套材料，手工整理的时间成本要算进去。
Q：在线工具安全吗？
上传 SQL 等于把表结构交给第三方。生产库的结构建议脱敏后再上传，或选支持自托管的方案（ChartDB、drawDB 都支持自托管）。
Q：生成的图和文档能直接交吗？
不能。任何工具生成的都是初稿：
- 图要核对实体、关系、基数
- 文档要补学校封面、目录、页眉页脚
- 文献要换成真实检索到的
- SQL 要在目标数据库实际执行
- 测试用例的"实际结果"必须真的跑过系统再填
Q：能不能用 AI 直接生成 SQL？
可以，但 AI 生成的 DDL 通常也没有外键约束，导进 ER 图工具同样会遇到"连不出线"的问题。建议生成后先人工补关系声明。
09｜小结
回到最初的问题：SQL 转 ER 图工具怎么选？
- 先看产出范围：只要图，还是连带一整套材料；
- 再看能不能补关系：SQL 没写外键时，工具能不能手工连上；
- 看中文支持：读不读
COMMENT，乱不乱码； - 看导出与编辑：格式够不够放进论文，能不能在线改；
- 安全：生产库结构先脱敏，或选自托管。
最后一句话：工具没有最好的，只有最匹配你下游需求的。如果你的流程到"导出 PNG 贴进论文"就结束了，开源工具完全够；如果后面还有数据字典、三线表、设计文档、答辩 PPT 要交，那就该选一个能让这些材料共享同一份结构的方案——省下来的不是画图时间，是改一遍要改六处的时间。
