三款Web端开源数据库ER图工具实测对比

做数据库设计的人大概都经历过那种尴尬表结构改了三轮ER 图还停留在最老的版本上。我最近整理一个老项目的数据库文档20 多张表的字段、外键、索引都要梳理清楚还得画一张能放进 PPT 的数据库 ER 图。翻了一圈手头能用的工具要么是客户端软件要装驱动要么是商业授权收费最后我把目光锁在三款 Web 端可用的开源数据库 ER 图设计工具上。这篇文章就把我的实测体验完整写出来选型思路、每款工具怎么上手、适合什么场景、会踩哪些坑一次讲透。1. 先想清楚你需要的到底是“画图”还是“建模”1.1 ER 图工具和普通绘图工具的本质区别很多新人第一次接触 ER 图第一反应是打开 PPT 或者在线白板开始画矩形、拉箭头。画几张小表没问题一旦表超过十张字段超过三五十个白板式画法就完全失控了框线对不齐字体改到怀疑人生同事改了一个字段名你整个图都要手动同步。真正的数据库 ER 图设计工具核心价值在于它能理解“实体、属性、关系”这三层语义。它知道你画的那个矩形是一张表矩形的每一行是一个字段表与表之间的连线是外键关联连线的端点还能表达基数关系一对一、一对多、多对多。只有理解了这些语义工具才能帮你从建表 SQL 自动生成模型图或者反过来从模型图自动生成建表 SQL。这就是“绘图工具”和“建模工具”的分水岭。所以在选工具之前你得先问自己一个问题我画这张 ER 图是为了给人看还是为了给数据库用如果只是给同事讲清楚表结构普通绘图工具勉强够用如果要让图成为数据库开发的依据那必须具备 SQL 导入导出能力。1.2 为什么我坚持用 Web 端开源方案这次选型我给自己定了两个硬条件必须 Web 端可用必须开源。Web 端可用意味着不用装客户端换电脑、换系统、临时在会议室机器上演示打开浏览器就能干活。团队里如果有人只是看看图、提个意见也不需要为 ta 专门装一套建模软件。开源意味着工具本身免费协议允许商用代码被人审计过不用担心上传的建表语句被人拿去训练模型或者卖数据。更要紧的是开源项目通常可以私有化部署到内网对数据敏感的业务来说这是商业 SaaS 很难替代的优势。当然Web 端开源方案也有代价功能丰富程度通常比不过商业客户端一些复杂建模能力要自己折腾。但对我日常梳理表结构、输出文档、做课程设计这类需求来说已经绰绰有余了。1.3 三类典型使用场景我这次梳理下来发现需要 ER 图的人大概分三类工具选择完全不同。第一类是“展示型需求”比如给新同事做数据库培训、给项目答辩做 PPT、给领导汇报表结构设计。这类场景看重的是图要好看、清晰、容易调整布局最好能直接导出 PNG、SVG。第二类是“文档型需求”比如把 ER 图写进项目 README、写进接口文档、放进代码仓库跟着版本走。这类场景看重的是文本化、可 diff、可自动渲染不需要手动拖拽布局。第三类是“设计型需求”比如新项目从零开始建表要先画模型、讨论字段、确认外键关系再生成建表脚本。这类场景看重的是 SQL 导入导出能力、字段类型支持、以及增量修改的便利性。我选出的三款工具恰好分别对应这三类场景。接下来一个个说。2. 三款工具实测diagrams.net、Mermaid、erd-editor2.1 diagrams.net全能型选手逆向生成 ER 图利器diagrams.net 这个工具老读者应该不陌生它以前叫 draw.io后来改了名字在线版地址是 app.diagrams.net桌面版和在线版并存开源协议是 Apache 2.0代码在 GitHub 上可以找到。说它是“全能型选手”是因为它的定位是一个通用图表绘制工具不只是画 ER 图。UML、流程图、架构图、思维导图、原型图它都能画。你要做 ER 图打开软件之后在左侧图形库里勾选“Entity Relation”或者“UML”相关的图形组就能找到常用的实体框、主键标记、关系连线。我实测最顺手的一条路径是逆向导入数据库里已经有一堆表我想快速生成对应的 ER 图。diagrams.net 提供了从 SQL 插入的功能入口在菜单栏 Extras 下面叫 Insert from SQL。点开之后选好数据库方言我通常选 MySQL然后把建表语句粘贴进去点插入工具会自动解析出实体框每个实体框里带着字段名和字段类型。如果 SQL 里写了外键它还能自动生成关系连线省掉大量手工拖线的功夫。举个例子我有一段最简单的两张表建表语句CREATE TABLE users ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, email VARCHAR(100) UNIQUE ); CREATE TABLE orders ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, total_amount DECIMAL(10,2), created_at DATETIME, CONSTRAINT fk_orders_user FOREIGN KEY (user_id) REFERENCES users(id) );粘贴进去之后diagrams.net 会生成 users 和 orders 两个实体框orders 表里有 user_id 字段外键连线也会一并出现。对于二十几张表生成出来的图通常比较乱需要手工整理位置、调整分组但总比从零开始画省力得多。反过来如果你处于正向设计阶段想先在图上画好模型再生成 SQLdiagrams.net 也能做。在 Extras 菜单里能找到编辑 SQL 配置的相关入口配置好生成规则之后它能把图形里的表结构转换成 DDL 脚本。不过说实话这个方向不如专业建模工具顺滑我更推荐在逆向导入的场景用它。优点很突出免费、跨平台、无需注册、图形样式丰富、支持导出 PNG/SVG/PDF还能对接 GitHub、GitLab、Google Drive 等存储方便团队共享。缺点也很明显它毕竟不是专门为数据库建模设计的字段类型校验、主外键语义、基数标记这些都需要自己维护图一旦大了布局整理非常费时间。2.2 Mermaid代码即图形把 ER 图写进 Git 文档第二款是 Mermaid准确说它是一个基于文本的图表渲染引擎开源协议是 MIT。它本身不提供图形化的拖拽界面而是用类似 Markdown 的文本语法描述图表然后渲染成 SVG 或 PNG。在线编辑器 mermaid.live 可以直接在浏览器里写文本看效果也可以导出图片。我第一次用 Mermaid 画 ER 图时觉得特别神奇不需要拖框、不需要连线只要把实体和关系用文本写出来它就能自动排版、自动布局。这对于习惯写代码的人来说比任何图形化工具都顺手。Mermaid 画 ER 图用的是 erDiagram 关键字实体定义放在大括号里字段可以用 PK、FK、UK 标记主键、外键和唯一键实体之间的关系用一组字符组合表达。我直接贴一段实测过的示例erDiagram CUSTOMER ||--o{ ORDER : places ORDER ||--|{ ORDER_ITEM : contains PRODUCT ||--o{ ORDER_ITEM : is included in CUSTOMER { int customer_id PK string name UK string email } ORDER { int order_id PK int customer_id FK datetime created_at } ORDER_ITEM { int order_item_id PK int order_id FK int product_id FK int quantity } PRODUCT { int product_id PK string name decimal price }这段文本放到 mermaid.live 里渲染出来的图有四个实体框字段、主外键都标得清清楚楚三对关系也会自动连线。特别适合直接写进 README、GitHub Wiki 或者 GitLab 的 Markdown 文档里任何人打开仓库都能看到最新的 ER 图。这里我踩过一个大坑必须提醒你Mermaid 的关系符号是有方向的||--o{这种写法左边是“一”端右边是“多”端。最常见的CUSTOMER ||--o{ ORDER读作“一个客户可以有零个或多个订单”语序是父实体在左、子实体在右。如果你把方向写反了渲染出来的关系语义就完全反了尤其是多对多关系拆成中间表的时候稍微不留神就把外键指反了。另外一个有意思的点是GitHub 和 GitLab 原生支持渲染 Mermaid 代码块也就是说你把带 mermaid 的代码块提交到仓库里在网页上打开这个文件时图表直接就显示出来了不需要任何插件。这一点对团队协作简直友好到不行ER 图跟着代码走Review 的时候谁改了哪个表、加了哪个字段在 diff 里看得一清二楚。Mermaid 的短板在于它是“自动布局”你没法手工拖动某个实体到指定位置微调排版的能力很弱。实体一多布局会显得比较密关系线交叉也难免。另外实体名和字段名的取值字符有一定限制如果表名带括号、引号、特殊符号需要按文档要求加双引号中文字段名在部分版本里会渲染异常我实际处理时习惯用英文表名和字段名中文含义单独写注释。如果你追求的是“一张图在文档里永远不过期”Mermaid 是目前最省心的方案没有之一。2.3 erd-editor为数据库建模而生的 Web 编辑器第三款是我这次新发现的开源工具GitHub 上叫 erd-editor是一款专门的 ER 图 Web 编辑器。它的定位和 diagrams.net 完全不同它是一个垂直的数据库建模工具打开网页就能看到左侧的实体列表、中间的画布、右侧的属性面板整个界面更像 Navicat 这类数据库客户端的模型设计器。我是在搜索“开源 ER 图工具”的时候翻到它的仓库地址在 GitHub 的 erd-editor/erd-editorMIT 协议。它支持从数据库连接信息直连、也支持直接粘贴 DDL 文本实测中我用得最多的还是粘贴 DDL。操作流程很直观打开在线页面新建一个模型然后在左上角找到导入 SQL 的入口选择 MySQL 方言把建表语句粘贴进去点一下解析画布上就会自动生成各个实体框表名、字段名、字段类型、主外键标识都排得整整齐齐外键关系线也会自动连线。后续你可以拖拽实体框调整位置右侧属性面板里改字段名、改类型、加注释一切操作都是可视化响应。导出方面它支持导出 PNG、SVG 等图片格式也支持导出 SQL DDL。这点很实用我先在 erd-editor 里把新项目的模型画好确认无误后导出建表 SQL再扔到数据库里执行整个流程比手写 DDL 稳得多。我实际操作的一个场景是帮一个课程设计团队整理数据库模型。他们的表结构前前后后改了五六版每次改都靠口头沟通经常 A 改了 users 表、B 不知道两边 SQL 对不上。我把他们的历史 SQL 导入 erd-editor生成一张总览图发到群里后面每次改动先在工具里改模型、导出 SQL、再发变更说明沟通成本明显降下来了。优点方面erd-editor 对“数据库建模”这件事的理解比通用绘图工具深很多像是字段类型下拉选择、主外键标识、索引标记这些细节都做得比较到位而且它也支持连接真实数据库做反向工程。缺点方面项目的社区规模相对小中文资料少个别数据库方言的边缘类型可能解析不了我导入 Oracle 的某些脚本时就遇到过类型识别异常需要手工修正。如果你主要工作是数据库结构的设计和维护不是偶尔画两张示意图erd-editor 值得放进收藏夹。3. 三款工具横向对比与选型建议3.1 一张表看懂差异为了更直观地比较我把三款工具的核心参数整理成一张表。这里的“协作方式”我指的是多人同时维护同一份模型的方式不是说实时协作编辑。对比项diagrams.netMermaiderd-editor定位通用图表绘制文本渲染引擎数据库 ER 图建模工具开源协议Apache 2.0MITMITWeb 在线版app.diagrams.netmermaid.live官方在线 Demo是否可私有化部署支持支持支持逆向导入 ER 图SQL 脚本/JDBC 连接需自行生成文本SQL 脚本/数据库连接正向导出建表 SQL支持不支持支持图片导出PNG/SVG/PDF 等PNG/SVGPNG/SVG自动布局能力弱手动为主强自动布局中等可手动微调文档内嵌渲染插入图片Git 原生渲染插入图片上手难度低中低需记语法中适合人群所有人开发者、文档维护者数据库开发、建模人员这张表基本把三款工具的性格差别体现出来了。diagrams.net 强在外观和通用性Mermaid 强在文本化和版本管理erd-editor 强在建模语义和 SQL 往返能力。3.2 按场景选型不纠结如果你现在只想快速把现有数据库的表结构画成一张图发给同事或者放进 PPT直接选 diagrams.net。它的 SQL 导入入口最好找图形样式也最多画出来的图比较符合大众审美。唯一的心理准备是导入之后布局会比较乱你要预留半小时左右整理。如果你是开发者想把 ER 图沉淀到代码仓库里以后每次表结构变更都跟着代码提交、在线上文档里直接渲染成图那就用 Mermaid。你不用考虑布局只要维护文本Git 天然帮你记录了每一版变更。缺点是它不适合精细排版复杂模型的阅读体验弱一些。如果你是在做新项目的数据库设计需要频繁调整字段、讨论外键关系还要生成建表脚本erd-editor 最合适。它的建模语义会让你非常舒服改字段类型、换主键、加索引这些操作远比在通用画图工具里改矩形舒服。需要注意的是它的在线版本适合小项目和个人使用如果数据非常敏感建议部署到内网再用。我自己现在的组合方式是这样的新项目用 erd-editor 做正向建模画图、改字段、导 SQL 一条龙确认稳定之后把最终模型转成 Mermaid 文本写进 README保证文档里的 ER 图永远跟代码走。diagrams.net 则用来做临时的、对外展示的图比如培训材料、答辩 PPT。4. 实操中的常见坑与排查技巧4.1 diagrams.net 的 SQL 导入并不是万能解析器用 diagrams.net 从 SQL 生成 ER 图最常遇到的问题有三个。第一是方言不匹配。同一个 DDLMySQL 和 PostgreSQL 的写法差异很大比如 PostgreSQL 的 SERIAL 类型、JSONB 类型如果你在对话框里选的是 MySQL 方言解析结果就会残缺。解决方法是导入前先确认你要导入的脚本到底属于哪种数据库选对语言再粘贴。第二是外键关系识别不出来。很多现有项目的建表脚本里外键并不一定写在 CREATE TABLE 里而是后面单独用 ALTER TABLE 添加。diagrams.net 解析这种脚本时实体框能生成关系线却可能漏掉。我的排查方法是不只靠工具自动连线导入完成后自己对着数据库外键清单过一遍缺哪条线手动补上。第三是复杂类型的显示问题。比如字段类型带长度、带 unsigned、带注释导入后实体框里的文字又长又乱。这种没有特别好的办法只能接受它毕竟工具只是帮你快速生成一个底稿不是最终成品整理布局和精简显示还是得人工来。4.2 Mermaid 的关系语法最容易搞反Mermaid 的 ER 图语法本身不难难的是把关系语义写对。我第一次写多对多关系的时候老老实实建了中间表 ORDER_ITEM结果关系连线全画反了后来才发现问题出在方向理解上。常见的几个关系符号我建议直接记住这张表符号语义}o--o--o{核心记忆方法是竖线越多约束越严格字母 o 表示可选项花括号 { 表示“多”。写关系的时候把父实体写在左边、子实体写在右边形成“一 对 多”的习惯能够减少大部分错误。另一个 mermaid 的坑是特殊字符。如果表名是order这种跟关键字重叠的词或者是user info这种带空格的词直接用是不行的需要给实体名加双引号。字段名同理。写中文表名在我测试的版本里也能渲染但有边界情况会失败为了稳妥我建议实体和字段统一用英文中文注释放在实体描述里或者干脆写在文档正文中。4.3 erd-editor 部署与协作注意事项erd-editor 的在线版本用起来很方便但有一个事我特别想提醒不要随手把含敏感表结构的 SQL 直接粘贴到第三方在线页面上。数据库表结构本身属于重要的业务信息用户表、订单表、支付表的字段设计逆向推导出业务逻辑一点都不难。如果你在给企业做项目或者涉及真实业务数据务必优先选择内网部署或离线使用的方式。GitHub 仓库里提供了自部署的路径前端构建产物可以托管在任何静态服务上也支持 Docker 方式一键起服务。我在内网服务器上部署过一次过程不复杂之后访问的就是内网地址数据不经过公网心里踏实很多。还有一个小建议不管用哪款工具ER 图画完之后最好导出一次 PDF 或者 PNG 存档。尤其是做课程设计或者项目验收的时候有图有真相等到答辩前一晚再发现图丢了那个滋味不好受。我自己吃过这个亏现在养成了每周五把画布导出备份的习惯。4.4 一张问题速查表最后把我实际踩过的一些高频问题整理成速查表方便你在现场直接对着排查。问题表现可能原因处理办法diagrams.net 导入 SQL 后缺少关系线外键在 ALTER TABLE 中单独添加自动导入后手动补线或先合并外键到建表语句diagrams.net 实体框文字混乱字段类型带长度和注释导入后手动精简字段展示Mermaid 图渲染报错实体名包含保留字或空格给实体名加双引号Mermaid 图方向不对关系符号左右方向理解反了参照上表逐条核对符号语义erd-editor 导入 Oracle DDL 类型异常方言边缘类型不支持先转成通用 SQL再手工修正字段类型导出图片字体发虚SVG 转 PNG 时字体渲染问题导出 SVG 后用浏览器打开再转高分辨率 PNG5. 最后说点我自己的使用体会工具这东西没有绝对的好坏只有合不合适。我这次从需求出发筛完一圈最大的感受是三款工具并不冲突它们分别解决“画得好看”“改得方便”“建得专业”这三种诉求关键看你在什么阶段需要什么。如果你现在正被一堆表结构搞得焦头烂额我的建议是从 diagrams.net 开始先把你现有的表导入成图对全局有个直观认识。等你想把这份资产长期维护起来再引入 Mermaid 写进文档。真正开始新项目设计时erd-editor 会是你的得力帮手。最后还是那句老话再好的工具也只是手段把数据库关系想明白、把需求对齐才是真正的核心。工具能帮你节省画图的时间却不能替你做设计决策。希望这篇文章能让你少走点弯路选到趁手的那一款。