前阵子接手一个老系统重构第一件事不是看代码而是把数据库表关系理清楚。我习惯用 ER 图做梳理但当时手边没有一个 Web 端可用的开源数据库 ER 图设计工具——Navicat 的逆向工程图丑不说导出的图片还没法让同事在线评注。搜了一圈真正能满足“开源、Web 端、能画 ER 图”这三个条件的工具不多最后我留下了三款老牌可视化工具 WWW SQL Designer通用绘图神器 draw.io也就是 diagrams.net以及适合写进文档的 Mermaid erDiagram。这篇文章不打算做那种“工具清单搬运”我想把我实际部署、实际画图、实际踩坑的过程都讲一遍顺便给出可以直接照抄的选型建议。1. 为什么我不用桌面客户端也要在 Web 里画 ER 图先说清楚一个前提我并不是排斥桌面客户端。DBeaver、DataGrip、Navicat 我都用过逆向数据库表结构的能力都很强但如果目标是“让团队一起评审 ER 图”桌面客户端的体验就有点难受了。1.1 桌面客户端在协作场景下的三宗罪第一分发给别人很麻烦。你要么导出 PNG要么截图丢到群里看的人只能“看”不能自己拖动、隐藏、缩放一旦评审会上提出“订单表和支付表之间其实还有一个中间表”你又得切回客户端改完再导一次。第二每个人的环境不一样。有人 Windows有人 macOS有人 Linux装的数据库客户端版本还不一致就算大家都有 DBeaver各自连库的配置、驱动、插件也经常对不上沟通成本全耗在环境问题上了。第三保存的文件格式不通用。很多客户端导出的 ER 图文件只能在自家软件里打开离开那个软件这些成果就是一张死图。所以我定了一个原则只要不是必须连生产库做交互式实时分析ER 图设计这个动作尽量放到 Web 端去完成最好还需要满足几个硬指标。1.2 我看重开源 ER 图工具的四个硬指标我筛选工具时只盯四件事。第一必须开源。 ER 图本质上是团队的知识资产我不希望它被某个 SaaS 平台锁死。今天这个在线工具还能用明天突然改收费策略我的数据库设计文档就跟着遭殃。开源至少保证代码在本地最坏情况也能自己维护。第二必须能在浏览器里跑。部署到公司内网也好打开官方在线版本也好只要不需要每个使用者安装客户端协作门槛就低一大截。第三必须支持 SQL 的导入或导出。画 ER 图不是最终目的最终目的是把表结构落成建表 DDL或者反过来把现存数据库的 DDL 变成大家可以讨论的图形。如果一个工具只能画图不能和 SQL 互通那它就只是一个高级白板价值大打折扣。第四保存格式要尽量通用。XML、纯文本、Markdown 或者 SVG 都可以只要能进 Git能 diff能被后续工具继续加工。我不接受“导出之后没法二次编辑”的单向交付。1.3 筛完一圈后的结论说实话同时满足这四点的“专业 ER 图设计工具”并不像想象中那么多。很多打着“在线数据库设计器”旗号的网站是闭源 SaaS免费版还有表数量限制不少开源项目又只支持桌面端不能 Web 访问。最后我选定的三款各有侧重WWW SQL Designer 走的是经典可视化路线draw.io 走的是通用绘图路线Mermaid erDiagram 走的是代码化路线。下面逐个讲。2. WWW SQL Designer老牌纯 Web 可视化建模器WWW SQL Designer 是一个有点年头的项目作者是 Ondřej Žára源码在 GitHub 上可以找到。它的形态比较古典前端 JavaScript 画布后端 PHP 负责保存和加载 XML打开浏览器就能用不需要安装任何数据库客户端。我第一次用它的感受是“简单到几乎不用学”。没有账号体系没有项目列表打开就是一个空白画布左边一排工具按钮像极了十几年前的网页设计器。2.1 五分钟把服务跑起来因为项目是纯 PHP 的跑起来非常轻量。如果你本机装了 PHP可以这样启动git clone https://github.com/ondras/wwwsqldesigner.git cd wwwsqldesigner php -S 127.0.0.1:8080 -t .浏览器访问http://127.0.0.1:8080就能看到界面。如果没装 PHP用 XAMPP、MAMP、宝塔这类集成环境也可以原理都是把它放到 Web 服务器的根目录下。有一点要提前注意它有一个“保存到服务器”的功能需要 PHP 对配置的保存目录有写权限。如果文件权限不够保存时会报错但这不影响你把设计结果导出为本地 XML 文件。我的建议是第一次用的时候就先试一次“导出到本地”确认浏览器下载正常再考虑要不要配置服务端保存。2.2 从空白画布到一张可执行的建表 SQLWWW SQL Designer 的核心操作路径我拆成四步。第一步新建数据库。画布上右键或者点工具栏里的“Create table”会拖出一个表对象双击表头可以修改表名。第二步双击表主体进入字段编辑界面逐行添加字段。字段名、类型、长度、默认值以及是否为主键PK、是否自动递增AUTO_INCREMENT都在这里设置。第三步用工具栏里的“Relation”工具从一个表的主键字段拖到另一个表的关联字段它会自动生成连线并弹出关系选项。第四步点工具栏里的“Export SQL”选择目标数据库类型就能拿到建表 DDL。下面是我随手画一个“用户-订单”模型后导出的简化结果CREATE TABLE customer ( customer_id int NOT NULL AUTO_INCREMENT, name varchar(100) DEFAULT NULL, PRIMARY KEY (customer_id) ); CREATE TABLE order ( order_id int NOT NULL AUTO_INCREMENT, customer_id int DEFAULT NULL, PRIMARY KEY (order_id) ); ALTER TABLE order ADD FOREIGN KEY (customer_id) REFERENCES customer (customer_id);它能直接拿到 MySQL 里执行省去手工建模的不少体力活。2.3 用下来要注意的四个坑第一字段类型集合是固定的。界面下拉框里只有 MySQL、PostgreSQL、Oracle 等几种常见类型如果你用到了比较偏门的自定义类型需要手动改导出后的 SQL或者去改源码里的类型定义。第二导入 SQL 的能力比较“老实”。它可以识别标准 CREATE TABLE 和 ALTER TABLE 外键语句但遇到复杂的存储过程、触发器、分区表定义基本会忽略或报错。所以它更适合“从模型生成 SQL”不太适合“从老库逆向成精美模型”。第三画布在表数量超过三四十张后会明显卡顿。它不是为超大规模数据库设计的做小型业务系统或者子模块建模很顺手做全企业级上千张表的设计会很难受。第四界面很朴素没有现代工具的暗色主题、自动布局、多人协同如果你追求视觉精美它的默认输出确实不够好看。不过它有一个桌面工具比不了的优势整站就是一个 PHP 项目丢到内网服务器就能用数据完全在自己的掌控中。适合团队内部快速建模不需要把业务表结构泄露给第三方平台。3. draw.io / diagrams.net不是专用 ER 工具但能做出最漂亮的交付图如果非要让我给“ER 图”选一个所有人都能打开的 Web 工具我会毫不犹豫选 draw.io。这个项目在 GitHub 上叫 jgraph/drawio开源协议是 Apache 2.0官方在线版 diagrams.net 免费使用同时也可以下载源码自托管。你打开网页就是画布不需要注册画完的文件可以存成本地.drawio文件也可以直接存到 GitHub、GitLab、OneDrive 这些地方。很多人觉得 draw.io 只是通用绘图工具画架构图、流程图用的和数据库 ER 图没什么关系。这其实低估了它。它自带数据库实体关系图的模板和形状库更重要的是它内置了一个“从 SQL DDL 生成 ER 图”的能力直接把建表语句变成图形。3.1 用 DDL 自动生成实体关系图我通常的做法是先从数据库里把表结构的 DDL 导出来然后粘贴到 draw.io 里自动生成。不同版本菜单路径略有差异英文版一般在Arrange - Insert - Advanced - From SQL中文版在“排列 - 插入 - 高级 - 来自 SQL”附近。如果你找不到直接在菜单栏搜索 “SQL” 会更稳妥。我测试过这样一个简单的 DDLCREATE TABLE students ( id INT PRIMARY KEY, name VARCHAR(100) ); CREATE TABLE courses ( id INT PRIMARY KEY, title VARCHAR(100) ); CREATE TABLE student_courses ( student_id INT, course_id INT, PRIMARY KEY (student_id, course_id), FOREIGN KEY (student_id) REFERENCES students(id), FOREIGN KEY (course_id) REFERENCES courses(id) );draw.io 会识别出三张表、三个主键字段、两个外键关系并自动画出三张带字段列表的数据表矩形以及它们之间的关系线。生成后你可以在画布里继续拖动调整位置改变关系线颜色、增加标签、添加容器分组。3.2 让 ER 图从“能看”到“能评审”自动生成的图一开始往往很乱关系线交叉、表位置重叠直接发给别人看会留下“很不专业”的印象。我总结了一套整理流程。先用容器按业务模块分组。比如把用户中心相关的表放进一个泳道或矩形框里订单中心放进另一个这样评审时能一眼看清边界。再给关系线补上基数标签。draw.io 默认生成的连线只有一条线我在连线上双击标上1、0..*、1..*这些关系说明必要时加一行文字解释“这条外键代表什么业务含义”。然后给表加颜色区分核心表、日志表、字典表核心表用暖色字典表用冷色日志表用灰色。最后加一个图例说明颜色、线型以及主外键图标的含义。导出的时候我会同时输出两份一份可编辑的.drawioXML 文件放进 Git 仓库方便以后修改和对比版本另一份 SVG 或 PNG用于写周报、评审文档和对外分享。SVG 还有一个好处是可以让前端同事直接放到内部知识库里还能保持清晰度。3.3 有几件事必须提前知道draw.io 虽然能生成 ER 图但它并不是数据库建模工具。它生成的表和关系线只是一些绘图对象不具备模型语义你在画布里改了一个字段名不会同步回 SQL把一张表删掉也不会帮你生成相应的 DROP 语句。它不直连数据库官方在线版默认没有“连上 MySQL 自动反向生成表结构”的功能。所以我的定位很明确draw.io 负责“画得漂亮”和“评审好看”不负责“建模严谨”。如果你要的是打开工具、连上数据库、自动出来全套 ER 图然后还能从模型直接改表结构并同步回生产库那 draw.io 不合适你该用专业的数据库建模客户端。4. Mermaid erDiagram把 ER 图写进代码仓库的最佳选择前两款工具都是图形化操作Mermaid 走的完全是另一条路用纯文本描述实体和关系然后让工具渲染成图。Mermaid 本身是开源的官方在线编辑器 mermaid.live 可以在浏览器里直接预览所以它也满足“Web 端可用”这个条件。我第一次用 Mermaid 画 ER 图是在写技术方案文档的时候突然想画张表结构图又不想切去截图就在 Markdown 里直接写了一段 erDiagram刷新页面后图就出来了当时就觉得这个思路特别适合程序员。4.1 为什么我建议用文本画 ER 图文本最直接的好处是能进 Git。字段调整、关系变化别人在 Pull Request 里看到的是一行一行的 diff而不是一张模糊的图片截图老同事走一遍 code review新旧 ER 图哪里变了就一目了然。另一个好处是不再需要专门的绘图软件只要有一个能渲染 Mermaid 的环境就行GitHub Markdown 支持、Notion 支持、各种静态站点生成器也支持。对于以文档驱动开发的技术团队来说这套工作流比“画图软件导图贴文档”要顺畅得多。4.2 erDiagram 语法入门Mermaid 的 ER 图语法分两部分实体定义和关系定义。关系写在最前面实体块放在后面。以“用户-订单-商品”为例erDiagram customer ||--o{ order : places order ||--|{ order_item : contains order_item }o--|| product : includes customer { int customer_id PK string name } 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 sku decimal price }这段代码渲染出来后能看到四张实体表每个字段前面是类型后面可以标PK或FK表之间会自动生成连线。语法非常简单没有图形工具的前置学习成本照着已有 DDL 就能改出来。4.3 关系基数搞清楚那串符号刚接触的人最容易在关系符号上懵掉。Mermaid 的关系线两侧各有两个字符左边描述“左侧实体的基数”右边描述“右侧实体的基数”。常见的符号如下符号含义||恰好一个|o零个或一个o{零个或多个|{一个或多个所以customer ||--o{ order的意思是一个客户可以有零个或多个订单而每个订单有且仅有一个客户。写关系线时最重要的是分清主体和从体。把||放在“一”的那一侧把o{或|{放在“多”的那一侧顺序颠倒会导致关系语义完全相反。4.4 在 Web 预览之外还能把渲染接入 CIMermaid Live Editor 适合临时画图、调试语法。如果希望每次代码合并后自动生成最新的 ER 图文件可以配合官方的 mermaid-cli 使用。我在一个内部项目里写过这样的命令npx -y mermaid-js/mermaid-cli -i schema.mmd -o schema.svg这里schema.mmd是存放 ER 图文本的文件schema.svg是渲染出的图片。把这个命令放到 CI 脚本里只要 schema.mmd 有更新SVG 就会自动重新生成。文档永远和代码同步不需要人手去“记得导图”。4.5 它的短板也很明显Mermaid 不是数据库建模器不支持反向导入数据库也不支持从图形拖拽生成 SQL。它的定位更像是一种“表达语言”适合把已经定好的表结构画成文档不适合用来做设计探索。另外cypher 复杂关系多了以后文本里的关系线很容易读晕不如图形工具直观。所以我的使用习惯是定稿后的 ER 展示用 Mermaid设计阶段的思考和讨论还是回图形工具更舒服。5. 三款工具横向对比与选型建议三款工具各有各的脾气放在一起对比会清晰很多。下面是我自己的评估表不追求面面俱到只写实际用下来影响选择的关键项。评估维度WWW SQL Designerdraw.io / diagrams.netMermaid erDiagram开源免费是是是Web 端使用自托管后在浏览器使用官方在线/自托管均可官方在线编辑器/嵌入 Web可视化拖拽支持支持不支持文本驱动数据库直连不支持不支持不支持SQL DDL 导入支持基础导入支持通过从 SQL 生成不支持需手写SQL DDL 导出支持多数据库类型导出不支持仅绘图不支持需另写脚本文件可进 Git支持 XML支持 .drawio/XML/SVG天然纯文本上手成本很低很低需要学会语法适合场景快速设计表结构生成 DDL评审展示、对外交付、架构图文档维护、代码仓库、自动化渲染选型建议我按角色拆开说如果你是后端开发主要精力在写业务代码只希望文档里有一张能跟着代码走的 ER 图优先选 Mermaid。它最轻改起来也顺手。如果你要和产品、测试、甲方过方案需要对着一张“看起来专业”的图做评审draw.io 是首选。它最擅长把复杂关系整理成清晰美观的模块图。如果你正在做新系统的数据库建模想快速画表、拉关系顺手把建表 SQL 生成出来那 WWW SQL Designer 更对口它是三款里唯一一个把模型和 SQL 真正联动起来的工具。如果你的团队有内网部署需求不想让表结构出现在任何外部平台WWW SQL Designer 和 draw.io 都能自托管Mermaid 则完全不存在数据出网的问题因为它就是一段文本。6. 我的真实选型经验什么情况下别迷信工具工具讲到最后还是得回到实际工作流。我个人踩过不少次“为了用工具而用工具”的坑这里说点真话。6.1 ER 图的核心不是工具而是关系边界早年间我很热衷找好用的建模工具后来发现很多项目的 ER 图画不好不是工具不行而是压根没把表之间的关系想清楚。比如订单表和用户表到底是1:N还是N:M中间表要不要冗余状态字段放哪张表这些问题靠换工具解决不了。画出来的图丑一点、乱一点只要关系清楚评审会上大家还是能看懂反过来工具再贵再智能表的边界本身就是糊涂的ER 图只会更难看。6.2 我最后固定下来的工作流现在我处理一个模块时通常是这样组合的先用 SQL 或者 WWW SQL Designer 快速把核心表和字段列出来跑通主外键关系等到结构稳定了把 DDL 丢到 draw.io 里整理成评审用的版本模块边界、基数和图例都标清楚评审通过后再给这个 ER 模型维护一份 Mermaid 文本放到项目文档里作为长期可追溯的版本记录。这个流程的好处是一份模型源两个展示出口。模型源是真实的 SQL DDLdraw.io 服务于阶段性评审Mermaid 服务于日常文档阅读。不会出现“画图画得很开心但建表 SQL 居然没人维护”的尴尬局面。6.3 一个小建议如果你也在选 Web 端可用的开源数据库 ER 图设计工具我建议先别急着下载全家桶按你的实际使用场景在这三款里选一个拿当前项目里最复杂的一张表结构做试用重点关注三件事能不能准确导入或导出 SQL改完关系后别人能不能轻松评审生成的文件能不能长期保存并进入版本管理。跑通了再决定不然再好看的工具图也救不了混乱的表结构。 开源Web端ER图设计工具对比：从SQL到可视化建模的实战选型
前阵子接手一个老系统重构第一件事不是看代码而是把数据库表关系理清楚。我习惯用 ER 图做梳理但当时手边没有一个 Web 端可用的开源数据库 ER 图设计工具——Navicat 的逆向工程图丑不说导出的图片还没法让同事在线评注。搜了一圈真正能满足“开源、Web 端、能画 ER 图”这三个条件的工具不多最后我留下了三款老牌可视化工具 WWW SQL Designer通用绘图神器 draw.io也就是 diagrams.net以及适合写进文档的 Mermaid erDiagram。这篇文章不打算做那种“工具清单搬运”我想把我实际部署、实际画图、实际踩坑的过程都讲一遍顺便给出可以直接照抄的选型建议。1. 为什么我不用桌面客户端也要在 Web 里画 ER 图先说清楚一个前提我并不是排斥桌面客户端。DBeaver、DataGrip、Navicat 我都用过逆向数据库表结构的能力都很强但如果目标是“让团队一起评审 ER 图”桌面客户端的体验就有点难受了。1.1 桌面客户端在协作场景下的三宗罪第一分发给别人很麻烦。你要么导出 PNG要么截图丢到群里看的人只能“看”不能自己拖动、隐藏、缩放一旦评审会上提出“订单表和支付表之间其实还有一个中间表”你又得切回客户端改完再导一次。第二每个人的环境不一样。有人 Windows有人 macOS有人 Linux装的数据库客户端版本还不一致就算大家都有 DBeaver各自连库的配置、驱动、插件也经常对不上沟通成本全耗在环境问题上了。第三保存的文件格式不通用。很多客户端导出的 ER 图文件只能在自家软件里打开离开那个软件这些成果就是一张死图。所以我定了一个原则只要不是必须连生产库做交互式实时分析ER 图设计这个动作尽量放到 Web 端去完成最好还需要满足几个硬指标。1.2 我看重开源 ER 图工具的四个硬指标我筛选工具时只盯四件事。第一必须开源。 ER 图本质上是团队的知识资产我不希望它被某个 SaaS 平台锁死。今天这个在线工具还能用明天突然改收费策略我的数据库设计文档就跟着遭殃。开源至少保证代码在本地最坏情况也能自己维护。第二必须能在浏览器里跑。部署到公司内网也好打开官方在线版本也好只要不需要每个使用者安装客户端协作门槛就低一大截。第三必须支持 SQL 的导入或导出。画 ER 图不是最终目的最终目的是把表结构落成建表 DDL或者反过来把现存数据库的 DDL 变成大家可以讨论的图形。如果一个工具只能画图不能和 SQL 互通那它就只是一个高级白板价值大打折扣。第四保存格式要尽量通用。XML、纯文本、Markdown 或者 SVG 都可以只要能进 Git能 diff能被后续工具继续加工。我不接受“导出之后没法二次编辑”的单向交付。1.3 筛完一圈后的结论说实话同时满足这四点的“专业 ER 图设计工具”并不像想象中那么多。很多打着“在线数据库设计器”旗号的网站是闭源 SaaS免费版还有表数量限制不少开源项目又只支持桌面端不能 Web 访问。最后我选定的三款各有侧重WWW SQL Designer 走的是经典可视化路线draw.io 走的是通用绘图路线Mermaid erDiagram 走的是代码化路线。下面逐个讲。2. WWW SQL Designer老牌纯 Web 可视化建模器WWW SQL Designer 是一个有点年头的项目作者是 Ondřej Žára源码在 GitHub 上可以找到。它的形态比较古典前端 JavaScript 画布后端 PHP 负责保存和加载 XML打开浏览器就能用不需要安装任何数据库客户端。我第一次用它的感受是“简单到几乎不用学”。没有账号体系没有项目列表打开就是一个空白画布左边一排工具按钮像极了十几年前的网页设计器。2.1 五分钟把服务跑起来因为项目是纯 PHP 的跑起来非常轻量。如果你本机装了 PHP可以这样启动git clone https://github.com/ondras/wwwsqldesigner.git cd wwwsqldesigner php -S 127.0.0.1:8080 -t .浏览器访问http://127.0.0.1:8080就能看到界面。如果没装 PHP用 XAMPP、MAMP、宝塔这类集成环境也可以原理都是把它放到 Web 服务器的根目录下。有一点要提前注意它有一个“保存到服务器”的功能需要 PHP 对配置的保存目录有写权限。如果文件权限不够保存时会报错但这不影响你把设计结果导出为本地 XML 文件。我的建议是第一次用的时候就先试一次“导出到本地”确认浏览器下载正常再考虑要不要配置服务端保存。2.2 从空白画布到一张可执行的建表 SQLWWW SQL Designer 的核心操作路径我拆成四步。第一步新建数据库。画布上右键或者点工具栏里的“Create table”会拖出一个表对象双击表头可以修改表名。第二步双击表主体进入字段编辑界面逐行添加字段。字段名、类型、长度、默认值以及是否为主键PK、是否自动递增AUTO_INCREMENT都在这里设置。第三步用工具栏里的“Relation”工具从一个表的主键字段拖到另一个表的关联字段它会自动生成连线并弹出关系选项。第四步点工具栏里的“Export SQL”选择目标数据库类型就能拿到建表 DDL。下面是我随手画一个“用户-订单”模型后导出的简化结果CREATE TABLE customer ( customer_id int NOT NULL AUTO_INCREMENT, name varchar(100) DEFAULT NULL, PRIMARY KEY (customer_id) ); CREATE TABLE order ( order_id int NOT NULL AUTO_INCREMENT, customer_id int DEFAULT NULL, PRIMARY KEY (order_id) ); ALTER TABLE order ADD FOREIGN KEY (customer_id) REFERENCES customer (customer_id);它能直接拿到 MySQL 里执行省去手工建模的不少体力活。2.3 用下来要注意的四个坑第一字段类型集合是固定的。界面下拉框里只有 MySQL、PostgreSQL、Oracle 等几种常见类型如果你用到了比较偏门的自定义类型需要手动改导出后的 SQL或者去改源码里的类型定义。第二导入 SQL 的能力比较“老实”。它可以识别标准 CREATE TABLE 和 ALTER TABLE 外键语句但遇到复杂的存储过程、触发器、分区表定义基本会忽略或报错。所以它更适合“从模型生成 SQL”不太适合“从老库逆向成精美模型”。第三画布在表数量超过三四十张后会明显卡顿。它不是为超大规模数据库设计的做小型业务系统或者子模块建模很顺手做全企业级上千张表的设计会很难受。第四界面很朴素没有现代工具的暗色主题、自动布局、多人协同如果你追求视觉精美它的默认输出确实不够好看。不过它有一个桌面工具比不了的优势整站就是一个 PHP 项目丢到内网服务器就能用数据完全在自己的掌控中。适合团队内部快速建模不需要把业务表结构泄露给第三方平台。3. draw.io / diagrams.net不是专用 ER 工具但能做出最漂亮的交付图如果非要让我给“ER 图”选一个所有人都能打开的 Web 工具我会毫不犹豫选 draw.io。这个项目在 GitHub 上叫 jgraph/drawio开源协议是 Apache 2.0官方在线版 diagrams.net 免费使用同时也可以下载源码自托管。你打开网页就是画布不需要注册画完的文件可以存成本地.drawio文件也可以直接存到 GitHub、GitLab、OneDrive 这些地方。很多人觉得 draw.io 只是通用绘图工具画架构图、流程图用的和数据库 ER 图没什么关系。这其实低估了它。它自带数据库实体关系图的模板和形状库更重要的是它内置了一个“从 SQL DDL 生成 ER 图”的能力直接把建表语句变成图形。3.1 用 DDL 自动生成实体关系图我通常的做法是先从数据库里把表结构的 DDL 导出来然后粘贴到 draw.io 里自动生成。不同版本菜单路径略有差异英文版一般在Arrange - Insert - Advanced - From SQL中文版在“排列 - 插入 - 高级 - 来自 SQL”附近。如果你找不到直接在菜单栏搜索 “SQL” 会更稳妥。我测试过这样一个简单的 DDLCREATE TABLE students ( id INT PRIMARY KEY, name VARCHAR(100) ); CREATE TABLE courses ( id INT PRIMARY KEY, title VARCHAR(100) ); CREATE TABLE student_courses ( student_id INT, course_id INT, PRIMARY KEY (student_id, course_id), FOREIGN KEY (student_id) REFERENCES students(id), FOREIGN KEY (course_id) REFERENCES courses(id) );draw.io 会识别出三张表、三个主键字段、两个外键关系并自动画出三张带字段列表的数据表矩形以及它们之间的关系线。生成后你可以在画布里继续拖动调整位置改变关系线颜色、增加标签、添加容器分组。3.2 让 ER 图从“能看”到“能评审”自动生成的图一开始往往很乱关系线交叉、表位置重叠直接发给别人看会留下“很不专业”的印象。我总结了一套整理流程。先用容器按业务模块分组。比如把用户中心相关的表放进一个泳道或矩形框里订单中心放进另一个这样评审时能一眼看清边界。再给关系线补上基数标签。draw.io 默认生成的连线只有一条线我在连线上双击标上1、0..*、1..*这些关系说明必要时加一行文字解释“这条外键代表什么业务含义”。然后给表加颜色区分核心表、日志表、字典表核心表用暖色字典表用冷色日志表用灰色。最后加一个图例说明颜色、线型以及主外键图标的含义。导出的时候我会同时输出两份一份可编辑的.drawioXML 文件放进 Git 仓库方便以后修改和对比版本另一份 SVG 或 PNG用于写周报、评审文档和对外分享。SVG 还有一个好处是可以让前端同事直接放到内部知识库里还能保持清晰度。3.3 有几件事必须提前知道draw.io 虽然能生成 ER 图但它并不是数据库建模工具。它生成的表和关系线只是一些绘图对象不具备模型语义你在画布里改了一个字段名不会同步回 SQL把一张表删掉也不会帮你生成相应的 DROP 语句。它不直连数据库官方在线版默认没有“连上 MySQL 自动反向生成表结构”的功能。所以我的定位很明确draw.io 负责“画得漂亮”和“评审好看”不负责“建模严谨”。如果你要的是打开工具、连上数据库、自动出来全套 ER 图然后还能从模型直接改表结构并同步回生产库那 draw.io 不合适你该用专业的数据库建模客户端。4. Mermaid erDiagram把 ER 图写进代码仓库的最佳选择前两款工具都是图形化操作Mermaid 走的完全是另一条路用纯文本描述实体和关系然后让工具渲染成图。Mermaid 本身是开源的官方在线编辑器 mermaid.live 可以在浏览器里直接预览所以它也满足“Web 端可用”这个条件。我第一次用 Mermaid 画 ER 图是在写技术方案文档的时候突然想画张表结构图又不想切去截图就在 Markdown 里直接写了一段 erDiagram刷新页面后图就出来了当时就觉得这个思路特别适合程序员。4.1 为什么我建议用文本画 ER 图文本最直接的好处是能进 Git。字段调整、关系变化别人在 Pull Request 里看到的是一行一行的 diff而不是一张模糊的图片截图老同事走一遍 code review新旧 ER 图哪里变了就一目了然。另一个好处是不再需要专门的绘图软件只要有一个能渲染 Mermaid 的环境就行GitHub Markdown 支持、Notion 支持、各种静态站点生成器也支持。对于以文档驱动开发的技术团队来说这套工作流比“画图软件导图贴文档”要顺畅得多。4.2 erDiagram 语法入门Mermaid 的 ER 图语法分两部分实体定义和关系定义。关系写在最前面实体块放在后面。以“用户-订单-商品”为例erDiagram customer ||--o{ order : places order ||--|{ order_item : contains order_item }o--|| product : includes customer { int customer_id PK string name } 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 sku decimal price }这段代码渲染出来后能看到四张实体表每个字段前面是类型后面可以标PK或FK表之间会自动生成连线。语法非常简单没有图形工具的前置学习成本照着已有 DDL 就能改出来。4.3 关系基数搞清楚那串符号刚接触的人最容易在关系符号上懵掉。Mermaid 的关系线两侧各有两个字符左边描述“左侧实体的基数”右边描述“右侧实体的基数”。常见的符号如下符号含义||恰好一个|o零个或一个o{零个或多个|{一个或多个所以customer ||--o{ order的意思是一个客户可以有零个或多个订单而每个订单有且仅有一个客户。写关系线时最重要的是分清主体和从体。把||放在“一”的那一侧把o{或|{放在“多”的那一侧顺序颠倒会导致关系语义完全相反。4.4 在 Web 预览之外还能把渲染接入 CIMermaid Live Editor 适合临时画图、调试语法。如果希望每次代码合并后自动生成最新的 ER 图文件可以配合官方的 mermaid-cli 使用。我在一个内部项目里写过这样的命令npx -y mermaid-js/mermaid-cli -i schema.mmd -o schema.svg这里schema.mmd是存放 ER 图文本的文件schema.svg是渲染出的图片。把这个命令放到 CI 脚本里只要 schema.mmd 有更新SVG 就会自动重新生成。文档永远和代码同步不需要人手去“记得导图”。4.5 它的短板也很明显Mermaid 不是数据库建模器不支持反向导入数据库也不支持从图形拖拽生成 SQL。它的定位更像是一种“表达语言”适合把已经定好的表结构画成文档不适合用来做设计探索。另外cypher 复杂关系多了以后文本里的关系线很容易读晕不如图形工具直观。所以我的使用习惯是定稿后的 ER 展示用 Mermaid设计阶段的思考和讨论还是回图形工具更舒服。5. 三款工具横向对比与选型建议三款工具各有各的脾气放在一起对比会清晰很多。下面是我自己的评估表不追求面面俱到只写实际用下来影响选择的关键项。评估维度WWW SQL Designerdraw.io / diagrams.netMermaid erDiagram开源免费是是是Web 端使用自托管后在浏览器使用官方在线/自托管均可官方在线编辑器/嵌入 Web可视化拖拽支持支持不支持文本驱动数据库直连不支持不支持不支持SQL DDL 导入支持基础导入支持通过从 SQL 生成不支持需手写SQL DDL 导出支持多数据库类型导出不支持仅绘图不支持需另写脚本文件可进 Git支持 XML支持 .drawio/XML/SVG天然纯文本上手成本很低很低需要学会语法适合场景快速设计表结构生成 DDL评审展示、对外交付、架构图文档维护、代码仓库、自动化渲染选型建议我按角色拆开说如果你是后端开发主要精力在写业务代码只希望文档里有一张能跟着代码走的 ER 图优先选 Mermaid。它最轻改起来也顺手。如果你要和产品、测试、甲方过方案需要对着一张“看起来专业”的图做评审draw.io 是首选。它最擅长把复杂关系整理成清晰美观的模块图。如果你正在做新系统的数据库建模想快速画表、拉关系顺手把建表 SQL 生成出来那 WWW SQL Designer 更对口它是三款里唯一一个把模型和 SQL 真正联动起来的工具。如果你的团队有内网部署需求不想让表结构出现在任何外部平台WWW SQL Designer 和 draw.io 都能自托管Mermaid 则完全不存在数据出网的问题因为它就是一段文本。6. 我的真实选型经验什么情况下别迷信工具工具讲到最后还是得回到实际工作流。我个人踩过不少次“为了用工具而用工具”的坑这里说点真话。6.1 ER 图的核心不是工具而是关系边界早年间我很热衷找好用的建模工具后来发现很多项目的 ER 图画不好不是工具不行而是压根没把表之间的关系想清楚。比如订单表和用户表到底是1:N还是N:M中间表要不要冗余状态字段放哪张表这些问题靠换工具解决不了。画出来的图丑一点、乱一点只要关系清楚评审会上大家还是能看懂反过来工具再贵再智能表的边界本身就是糊涂的ER 图只会更难看。6.2 我最后固定下来的工作流现在我处理一个模块时通常是这样组合的先用 SQL 或者 WWW SQL Designer 快速把核心表和字段列出来跑通主外键关系等到结构稳定了把 DDL 丢到 draw.io 里整理成评审用的版本模块边界、基数和图例都标清楚评审通过后再给这个 ER 模型维护一份 Mermaid 文本放到项目文档里作为长期可追溯的版本记录。这个流程的好处是一份模型源两个展示出口。模型源是真实的 SQL DDLdraw.io 服务于阶段性评审Mermaid 服务于日常文档阅读。不会出现“画图画得很开心但建表 SQL 居然没人维护”的尴尬局面。6.3 一个小建议如果你也在选 Web 端可用的开源数据库 ER 图设计工具我建议先别急着下载全家桶按你的实际使用场景在这三款里选一个拿当前项目里最复杂的一张表结构做试用重点关注三件事能不能准确导入或导出 SQL改完关系后别人能不能轻松评审生成的文件能不能长期保存并进入版本管理。跑通了再决定不然再好看的工具图也救不了混乱的表结构。