最近给一个老项目梳理数据库文档业务库里一百多张表相互关联客户端装了好几款看结构用 A 工具导出图片用 B 工具同事之间同步信息基本靠截图。这种状态下效率极低谁改了表结构都要喊一声“重新导一下图”。当时我脑子里冒出来的第一个需求很朴素有没有一款能在浏览器里直接打开、不怕公司不让装软件、还能自己部署到内网的开源 ER 图设计工具一查发现这类工具比我想象中成熟得多而且开源的不止一两款。我最后筛出了三款在 Web 端可用、完全开源、能拉到自己服务器上部署的 ER 图工具分别适合完全不同的使用场景。这篇文章没有按“工具 A、工具 B、工具 C”的老套评测模板写而是从实际需求出发说清楚每一款能解决什么问题、在什么场景下会翻车、具体怎么落地。如果你正被“MySQL 的表导 ER 关系图”“数据库课程设计要画 ER 图”“老系统表结构梳理”这些事情困扰这篇应该能帮你省不少折腾时间。1. 先聊聊我为什么从前几款桌面工具切到了 Web 端1.1 从一次课程设计式的需求说起很多人接触 ER 图都是因为“数据库课程设计”。当年我也干过这事用 Visio 一个框一个框地画实体再手动拉线表示关系交作业前反复调整布局眼睛都快看花了。后来工作里接手别人的 JavaWeb 项目数据库是 MySQL表有一百多张Navicat 里看单张表的结构没问题但想看整体关联关系就抓瞎了。更麻烦的是协作。设计评审会上产品和后端同事都要看表结构我不能要求每个人都装一遍 MySQL 客户端再把表结构导来导去。最理想的状态是发一个链接大家浏览器打开就能看能缩放、能拖拽、能导出图片放进文档而且这个工具最好能部署在我们自己的服务器上。顺着这个思路去找发现市面上的工具大概能分三类一类是 SaaS 在线服务随时可能因为免费额度限制或网络问题把图锁住一类是桌面客户端软件功能强大但没法多人实时查看第三类就是我现在要说的开源、并且可以通过 Web 访问的 ER 图设计工具。它们没有商业产品那么花哨但胜在可控、可部署、不用担心授权问题。1.2 Web 端 ER 图工具有几个桌面工具替代不了的优势首先是零安装。内网环境里往往有一堆安全限制公司电脑不允许随便装软件但浏览器是打开的。Web 端工具把整个编辑器通过浏览器页面提供解决了软件分发的问题。其次是共享方便。ER 图这东西画出来最终是要给别人看的。Web 端可以做成一个内部链接评审时投屏、发消息、嵌入内部文档系统都方便。部分工具还支持生成静态 HTML 文件双击就能看这对写数据库设计文档非常有用。第三是可二次开发。开源的意义不只是免费而是你能改。我见过一些团队把 ER 图工具嵌入到自己的数据平台里点表名直接跳 ER 图靠的就是工具暴露的 API 和源码。当然Web 端工具也不是没有短板。最明显的两个一是如果部署在自己的服务器上需要考虑内网访问带宽和浏览器兼容性二是部分工具的功能深度不如老牌桌面软件比如对逆向工程、复杂触发器支持有限。但我实际用下来应对绝大多数日常设计和文档工作完全够用。2. 三款开源工具先放在一张表里对比2.1 一张表看整体差异在详细介绍之前我把三款工具的核心信息整理成了一张对比表方便你先有个整体判断。对比项erd-editorChartDBdraw.iodiagrams.net项目类型纯前端 ER 图编辑器数据库逆向工程 ER 展示通用绘图工具部署方式本地启动、Docker、NPMNode.js / DockerDocker、官方 App是否支持数据库直连不支持只解析 SQL 文件支持支持多种数据库直连导入不支持核心上手难度极低开箱即用低但需要配数据库连接极低典型使用场景课程设计、新库设计、快速画图存量数据库逆向梳理、团队协作通用流程图、简单 ER 图开源协议MITAGPL-3.0Apache-2.0这里我要特别强调一件事这三款工具不是同一种东西的换皮。erd-editor 更偏“画图工具”ChartDB 更偏“数据库结构分析工具”draw.io 则是“通用绘图工具碰巧能做 ER 图”。选错方向会很痛苦比如你想做数据库逆向却选了个纯画图工具那导入表结构这一步就够你手动折腾半天。2.2 我的筛选标准开源、可部署、导入导出能力先说开源协议。选开源工具不能只看 GitHub 星标多不多要看 License。三款里面erd-editor 是 MIT商业公司拿去二次开发没有负担ChartDB 是 AGPL如果你只是内部使用没问题但如果要改造后作为对外服务就要考虑开源协议传染的问题draw.io 是 Apache-2.0相对宽松也允许商用。再说部署。我要求工具必须能部署在内网这样数据不出内网、访问快、不受外网服务影响。三款工具都能通过 Docker 镜像一键起服务安装过程都很简单。最后是导入导出能力。在实际项目里我们经常要做两类事情一类是从已有数据库里分析表关系生成 ER 图另一类是画好 ER 图后导出成 SQL DDL 或文档。这三款工具在导入导出上各有侧重下面详细展开。3. erd-editor最适合快速画图的轻量派课程设计和文档插图的优选3.1 部署和上手体验erd-editor 是我最早接触的 Web 端开源 ER 图工具。它的设计思路很纯粹打开编辑器画框、连线、导出不搞数据库连接、不搞账号体系所有数据都在浏览器本地处理。部署方式有两种一种是用 NPM 直接启动npx useatom/erd-editor执行完浏览器会自动打开一个本地页面默认端口可以看启动日志。这种方式适合本机临时用。如果想部署到服务器给团队用用 Docker 更省心docker run -d --name erd-editor -p 3000:3000 ghcr.io/useatom/erd-editor:latest启动后访问http://服务器IP:3000即可。页面上没有任何多余的东西就是一个画布加左侧的工具栏对新人非常友好。我第一次用时几乎没有学习成本。3.2 用 erd-editor 把 MySQL 表导出成 ER 图的完整流程很多人搜“mysql 的表导出 er 关系图”其实是在问怎么把现有 MySQL 表变成一张关系图。用 erd-editor 的标准流程是这样的第一步从数据库导出 DDL 脚本。Navicat、MySQL Workbench、命令行都可以。命令行最简单mysqldump -u root -p --no-data --skip-comments database_name schema.sql这里加--no-data是只导出表结构--skip-comments是去掉注释避免导入工具时出现编码问题。第二步在 erd-editor 页面里选择“从 SQL 文件导入”选刚导出的 schema.sql。工具会解析 DDL自动生成表关联关系并把外键连接线画出来。第三步微调布局。自动生成的图偶尔会乱需要对实体框的位置做手动拖拽。erd-editor 的拖拽体验很流畅连线会跟着实体位置自动调整不会有折线交叉特别严重的问题。第四步导出。它支持导出 PNG、SVG 图片也可以导出为 HTML 文件。我特别推荐导出 HTML 那个选项——导出的文件是一个单文件网页发给谁都能在浏览器里打开不需要装任何软件而且可以继续拖拽查看写数据库设计文档时极其好用。3.3 实际使用中的一些细节和局限erd-editor 的 UI 设计很克制但有几个细节我觉得很加分。一个是表的常用操作按钮做得很顺手比如快速添加字段、设置主键、调整字段类型另一个是支持 Markdown 说明我习惯在每个表下面写一行“这个表是干什么的”图看起来更清楚。不过它也有明显的局限它只认识你在画布上的内容不会主动连接数据库去拉真实表结构。如果你想要的是“填一个数据库地址自动把几十张表读出来并排版好”erd-editor 做不到这是它的定位决定的。另外如果表数量超过一百张画布缩放和拖拽会有轻微卡顿但还能接受。所以如果你只是做课程设计、画 ER 图用来交作业、或者想快速把十几张表的 DDL 变成一张设计图erd-editor 完全够用而且不折腾。三款里上手最快的就是它。4. ChartDB数据库逆向工程的一把好手存量系统梳理就靠它4.1 核心理念不画图先连接数据库ChartDB 是我最近才开始用的但一用就回不去了。它解决的痛点和 erd-editor 完全不一样当你的数据库已经跑了好几年、表多到没法手工拖拽时怎么快速地把整个库的结构可视化出来。它的官网介绍经常用一张“点击导入自动生成 ER 图”的截图来吸引用户实际用下来没有夸张。ChartDB 支持的数据库种类很多PostgreSQL、MySQL、SQL Server、MariaDB、SQLite、Oracle、Snowflake 等都在支持列表里。这意味着不管是开源数据库还是商业数据库它基本都能一网打尽。有人可能会问这功能 Navicat 不是也有吗数据库逆向功能确实不新鲜但 ChartDB 的优势是 Web 界面 团队协作。我可以在内网部署一个 ChartDB 服务团队成员共享同一个访问入口任何人想看表结构都能直接打开不用挨个装 Navicat也不用手动截图传群。这一点在日常工作中太实用了。4.2 Docker 部署与多数据库支持实测ChartDB 的部署方式非常简单官方提供了 Docker 镜像docker run --name chartdb -p 3587:3587 ghcr.io/chartdb/chartdb:latest启动后访问http://服务器IP:3587即可。整个服务是前后端一起打包的不需要额外安装 Node 环境。如果在国内服务器拉取镜像速度慢可以配置镜像加速器这个属于常规操作。连接数据库时需要填数据库地址、端口、用户名、密码和数据库名。这里我要提醒一句强烈建议使用只读账号来连。ChartDB 本身不会修改数据但如果账号权限过大一旦误操作仍然存在风险。只读账号是双保险。以 MySQL 为例连接信息填完点导入几十秒后就能看到一张完整的 ER 图。表与表之间的关系线、外键、主键都会自动标出来不需要手动处理。4.3 用北风数据库做一次完整的逆向体验为了验证它的效果我用经典的 Northwind北风数据库实测了一遍。这个库表不多大概十几张表但订单、产品、客户、供应商之间的关联关系很典型特别适合测试工具。导入完成后ChartDB 自动把所有表平铺在画布上并用外键关系线把表连接起来。我不用手动拖拽任何东西就可以通过滚轮缩放、点击表查看字段详情、直接看到哪些字段是主键、哪些是外键、关联到哪张表。这种“拿到手就是成品”的体验是纯画图工具给不了的。还有一个我用着很舒服的功能局部高亮关联链路。比如点击“Products”表它会把所有和 Products 有直接或间接关联的表高亮出来其他表变暗。分析数据流向时不需要自己在世界里乱找关系线。4.4 ChartDB 的使用局限ChartDB 目前给我的短板主要有两个。第一它不是画图导向的。如果你想设计一张全新的表在空白画布上从零开始画出 ER 图ChartDB 的体验反而不如 erd-editor。它的优势在于分析和展示不在于自由绘制。第二导入超大数据库时浏览器端渲染会有点吃力。我试过一次导入四百多张表的库画布加载完成后缩放操作明显有延迟。这种情况建议拆分成多个 Schema 来导或者用它的搜索和筛选功能只展示需要的部分。总体而言只要你手里有“数据库已经存在我要快速搞清楚它里面长什么样”的需求优先考虑 ChartDB 就对了。5. draw.io通用图表工具也能做 ER 图但别拿它搞大规模库表设计5.1 draw.io 里画 ER 图的具体姿势draw.io 其实大家都不陌生它是个老牌的在线绘图工具现在叫 diagrams.net。很多人不知道的是它默认自带一系列 ER 图相关的模板和形状库。我第一次用的时候在“模板”里直接搜“Entity Relationship”就找到了现成的 ER 模板里面有表实体框、主键字段、关系连线等基础元素。在 draw.io 里画 ER 图的逻辑和画流程图很像左侧图形库里拖出表实体双击编辑字段然后用连线工具把外键关联起来。连线样式可以设置成“实体关系”样式直角折线加 ID 两端标注接近教科书里的 ER 图画法。存储方面draw.io 很灵活可以保存到本地文件、GitHub、OneDrive、Google Drive也可以嵌入到内部 Wiki 系统。这个灵活度是三款工具里最高的。5.2 为什么我不建议把 draw.io 当作专业数据库表结构管理工具虽然 draw.io 能画 ER 图但它的定位是“通用图表工具”不是“数据库设计工具”。实际使用时会遇到几个问题第一没有 DDL 导入。你没法把一个 30 张表的 schema.sql 丢进去让 draw.io 自动生成表结构。每张表的字段都要手工录入字段一多光录入就是一项体力活而且容易手滑拼错字段名。第二没有字段类型校验。在专业 ER 工具里你添加一个字段时可以选择 int、varchar、decimal 等类型方便后续生成 SQL。draw.io 里图形框里的文字内容都是自由文本类型不类型全靠自己写画图时候挺爽真要拿它生成建表语句就抓瞎了。第三没有数据库连接能力。它就是一个纯粹的绘图工具不可能从运行中的数据库读表出来。所以我的结论是draw.io 适合偶尔画一张简单的 ER 示意图比如在方案评审会上给领导看一下大概的表关系或者放在文档里做个示意。但如果你要对真实数据库做结构管理、自动生成 DDL、反向梳理表关系请回到前两节说的工具。6. 三款工具怎么选以及我实际踩过的几个坑6.1 按场景直接给结论很多同学问“数据库 ER 图设计工具到底选哪个”其实答案取决于你要进入的状态。我帮你把场景拆开你的需求推荐选择核心理由交课程设计作业、画示意图、快速把 DDL 变成图erd-editor上手最快导出图片和单文件 HTML交作业足够库里已经有几十张表想反向梳理结构ChartDB一键直连数据库外键关系自动生成省去手工连线综合画图不限于 ER 图还要画流程图、架构图draw.io功能全面存储方式灵活通用性最强如果你正在做“ER 图转化为关系模型”的练习或项目有一点要清醒工具能帮你把表结构画出来、甚至生成 DDL但“实体转表、属性转字段、联系转外键”这套映射关系是数据库设计的基本功工具替代不了你的理解。我在帮人看毕业设计论文时见过不少画得漂亮但外键标错的 ER 图工具再好也得自己把关。6.2 部署和使用中容易踩的坑第一个坑中文乱码。erd-editor 和 draw.io 导出 PNG 时如果服务器或系统缺少中文字体图片里的中文会变成方框。解决办法是部署时在系统里安装中文字体或者导出 SVG 格式再自己转换。ChartDB 因为主要是浏览器渲染导出图片时也要注意浏览器所在的系统字体建议直接导出 PNG 前先预览确认。第二个坑端口冲突。上面给的 Docker 命令默认映射了 3000 或 3587 端口生产环境很容易跟现有服务撞上。建议启动前先用ss -lntp看下端口占用情况或者直接换一个高位端口映射。我自己就在一台服务器上因为端口被占用排查了半天才想起来是 Jenkins 占用了默认端口。第三个坑连接数据库时的白名单限制。ChartDB 连接数据库如果失败不一定是工具的问题很可能是目标数据库只允许本地访问或者防火墙没放行。如果数据库和 ChartDB 部署不在同一台机器上记得在数据库侧授权远程只读用户别一上来就给 root 开一个全网段可访问。第四个坑浏览器选择。Web 端工具对浏览器的兼容性依赖比较高建议统一用 Chrome 或者 Edge。我在某个内部系统里用旧版 Firefox 打开 erd-editor拖动实体框时会出现卡顿换个浏览器立刻好了。这种问题在文档里不太会写但实际遇到就很崩溃。第五个坑大表结构导入性能。如果你把整个库几百张表的 DDL 一次性导入 erd-editor解析和渲染都需要时间页面甚至会短暂假死。建议先分模块导入比如先导入订单模块再导入用户模块最后手工把模块之间的外键连起来。这不只是工具限制也是梳理大型数据库时更高效的方法。选型这种事没有绝对的“最好”只有“在当前场景下最合适”。我个人的习惯是同时部署其中两套一套 ChartDB 用来分析几个核心业务数据库的表结构一套 erd-editor 放在那边谁临时要画点图、做个提交文档的插图直接用就行。互不冲突也覆盖了最常用的两个场景你也不妨这样搭配试试。