写这篇文章的起因是最近又被一位同事问“有没有那种打开浏览器就能画数据库 ER 图的工具最好还是开源的”。我当时第一反应是直接甩给他一个桌面软件链接但转念一想他这边只是要给甲方演示一张表结构说明图装一个几 GB 的客户端实在没必要。类似需求我这两年碰到过不少次要么是团队里几个人要一起评审表结构要么是学生党做数据库课程设计要交一份能展示的 ER 图再不然就是我这种经常在多个项目之间切换的人实在不想每台机器都装一套工具。如果你的需求也是“Web 端可用 开源 数据库 ER 图”这三个条件同时满足那这篇文章应该能帮你省下不少折腾时间。我会把三款实测过的工具按场景拆开来讲包含部署方式、踩坑记录和选型建议。1. 为什么劝你放弃桌面端直接用 Web 端画 ER 图1.1 桌面 ER 工具的三大痛点安装、版本、分享桌面端的 ER 图工具其实并不少Navicat 自带的模型、DBeaver 的 ER 视图、付费的 dbschema、免费开源的 DBeaver 插件等都能画。但我实际用下来的感受是它们都有一个绕不开的共性麻烦必须先有数据库连接环境或者安装完整客户端才能开始画图。哪怕你只是想在开会前临时画两张表说明一下关联关系也得先把工具装好、把连接配置好这一套流程本身就劝退了一批只想“快速表达”的人。第二个痛点是版本和文件格式。很多桌面工具的项目文件是私有格式换一台电脑、换一个工具就打不开了。我见过不止一次同事用某个付费工具画完 ER 图后离职了项目文件直接在网盘里烂尾后来者只能重新画一遍。这个问题在 Web 端工具里其实更容易规避因为多数方案要么把文件存成标准 XML 或 JSON要么直接导出 SQL 脚本作为唯一事实来源。第三个痛点更扎心分享。桌面工具画完图你要发给别人看通常得导出 PNG 或者 PDF对方如果提出“能不能改一下这个字段名”你又得回到自己电脑上改完再导出一次。如果能让对方也打开同一个浏览器地址看到的图是同一份文件这种体验上的差距是本质性的。1.2 Web 端方案的三个优势刚好对症下药Web 端数据库 ER 图设计工具最大的价值就是把“画图”这件事从本地环境里解放出来。第一零安装。只要浏览器能打开Windows、macOS、Linux 甚至平板都无所谓打开一个 URL 就能用。第二跨平台协作。工具部署在公司内网或云服务器之后团队所有人访问的是同一份部署不存在“我这边能跑你那边跑不起来”的兼容性问题。第三方便自托管和版本管理。很多 Web 端方案允许你把数据文件存在 Git 仓库里或者输出标准 SQL这样 ER 图就不会被锁死在单一软件里。另外对于学生或者临时需求来说Web 端还有一个隐性的好处看起来更“轻”。做数据库课程设计的时候老师要求交一份 ER 图你说“我用在线工具画的链接在这里”比“这个文件要装 XX 软件才能打开”要省心太多。甚至在一些不允许随便安装软件的公司电脑上Web 端几乎是唯一可行路线。1.3 我筛选工具时的四个硬性标准这次我筛选工具并不只是“能用就行”而是定了几条硬性标准按顺序排除下来再留下的工具才是真正值得写进文章的。必须开源开源意味着可以自托管数据不出内网也意味着就算原项目不维护了代码还在你可以自己修。必须 Web 端可用要么是纯浏览器方案要么是安装后通过浏览器访问命令行工具如果最终产物是 HTML 静态站点也算符合条件因为它本质上是在提供一个 Web 查看方案。必须和数据库有关系ER 图工具不是普通画图板至少要支持从 SQL 导入、反向读取数据库、或者导出建表 SQL 这三者之一。文档和社区不能太冷门一个工具再强如果连官方文档都找不到出了问题只能自己啃源码那在实际项目里就是用脚投票。基于这四条标准我最终留下了三款draw.iodiagrams.net、WWW SQL Designer、SchemaSpy。后面会一个一个拆开讲。2. 3 款开源方案横评谁能直接在浏览器里连上数据库2.1 draw.io / diagrams.net通用绘图工具里的数据库专业户很多人印象里 draw.io 就是一个画流程图的工具但它的数据库能力被严重低估了。draw.io 也就是现在说的 diagrams.net开源协议是 Apache-2.0你可以直接用官方在线站点也可以 Docker 部署到自己服务器。它支持从 SQL 建表语句直接生成 ER 图也支持把画好的 ER 图导出成 MySQL、PostgreSQL 等数据库的 DDL 脚本这一进一出就让它在“数据库 ER 图设计工具”这个分类里有了非常硬核的位置。我经常这样形容 draw.io它相当于一个“什么都能画”的通用画布而数据库 ER 图只是它支持的众多能力之一。这样带来的好处是学习成本低、模板多、导出格式丰富坏处则是它不会主动帮你维护“表”和“字段”的概念如果你希望工具能感知到“这是主键、这是外键、这两个字段之间是 1 对 N 关系”就需要借助它的 SQL 导入功能来完成手动画的话它本质上还是画矩形和连线。从部署角度来看官方提供了 jgraph/drawio 这个 Docker 镜像一条命令就能在内网起一个独立实例。在线版 diagrams.net 默认会把数据存到浏览器本地、或者你授权的云端存储GitHub、GitLab、OneDrive、Google Drive 等自托管版也有对应的存储配置。对于很多公司来说数据通过浏览器保存在自己可控的 Git 仓库里这个安全边界是很清晰的。2.2 WWW SQL Designer真正的“浏览器里连库设计”如果说 draw.io 是“通用画布 数据库辅助”那 WWW SQL Designer 就是纯正的“数据库 ER 图专用工具”且整个操作界面就是浏览器。这个项目非常老牌最早可以追溯到 2000 年代GitHub 上现在还能找到ondras/wwwsqldesigner。技术栈是 PHP 后端 JavaScript 前端部署在一个支持 PHP 的 Web 服务器上就能跑它支持直接连接 MySQL 数据库读取现有表结构并生成 ER 图也支持从 SQL 文件导入、手工建表再导出建表语句。这个工具给我最大的好感是“纯粹”。打开页面就是一张画布左边是表、字段和关系工具右边是属性面板没有任何多余的东西。你可以在浏览器里直接填表名、加字段、设置主键、拖拽连线建立外键关系做完了直接导出 SQL 脚本。对于想快速从已有数据库得到一张图上交或者评审的场景它比 draw.io 更直接。不过也要说实话它的界面风格停留在老式 Web 应用水平颜值不高而且项目更新频率不高对 PHP 8 的兼容性有问题MySQL 以外的数据库支持也比较弱。但如果你只是要给 MySQL 库出一张 ER 图它是我用过的 Web 端工具里“最快能出结果”的一个。2.3 SchemaSpy不编辑但能把 ER 图发给全团队看SchemaSpy 和前面两个工具定位完全不同。它本身是一个 Java 命令行工具不提供实时编辑页面而是连接数据库后生成一个完整的多页 HTML 静态站点里面包含所有表的字段信息、索引、约束以及可以缩放查看的 ER 关系图。生成完毕之后你把整站丢到 Nginx 或者任意静态文件服务器上全公司的人就可以在浏览器里查看了。这个方案的价值在于“自动化”。你可以把 SchemaSpy 集成到 CI 流程里每次数据库结构变更后自动重新生成一份最新的 Web 版 ER 文档。它不需要设计师手动调整布局也不需要有人维护图片版本所有信息都来自数据库元数据天然准确。缺点也很明显它只能看和导出不能直接在上面编辑。很多人会问“不能编辑那它还算设计工具吗”我的看法是在真实项目里ER 图有“设计态”和“展示态”两种。画草图和改表结构属于设计态用 draw.io 或 WWW SQL Designer而把最终结构发布成文档给团队查阅则属于展示态SchemaSpy 是展示态里最省人力的一种实现方式。2.4 补充方案Mermaid Live Editor适合喜欢“写代码画图”的人如果你连部署都嫌麻烦也想绕开图形界面的拖拽操作可以试试 Mermaid Live Editor。这是纯浏览器端工具用类似文本标记的语法描述 ER 图结构比如写一行“用户表”和“订单表”以及它们的外键关系它就会渲染成可视化的 ER 图。Mermaid 本身也是开源项目而且 GitHub 的 Markdown 原生支持 Mermaid 渲染这意味着你可以直接把 ER 图源码写进 README别人浏览仓库时就能看到图。我没把它列为前三强的正式成员是因为它和“数据库”之间缺少一个自动化的桥你必须手动把表结构翻译成 Mermaid 语法。但它非常适合作为补充工具尤其是当你只想要一张轻量 ER 图放进文档里的时候手写语法往往比打开一个画布拖拽更快。具体语法很简单大致就是在这种文本里定义每个表的字段和关系具体关键词可以在官方文档里查到。用文本描述结构有一个额外的好处它天然适合 Git 协作和代码评审。2.5 三款工具核心参数对照表工具是否纯 Web 端开源协议数据库接入方式能否在线编辑最适合场景draw.io / diagrams.net在线 可自托管Apache-2.0导入 SQL DDL、可配置外部存储能通用画图、评审图、手动画 ERWWW SQL Designer纯 Web部署 PHPGPL直连 MySQL、导入 SQL能快速逆向 MySQL 生成 ER 图SchemaSpy生成静态 HTML 供浏览器查看LGPL直连多款数据库并生成 HTML 文档否自动化生成数据库文档、团队查阅Mermaid Live Editor补充纯 WebMIT手动书写结构语法能改文本把 ER 图写进 Markdown 文档3. 从 SQL 到 ER 图三款工具的完整落地步骤3.1 实战一用 draw.io 把 MySQL 建表 SQL 变成 ER 图先说场景你手上有一份 MySQL 的建表 SQL 文件想在几分钟内得到一张排版整齐的 ER 图。用 draw.io 处理这个需求是最快的路径。第一步打开 diagrams.net 在线版或者访问你自己部署的实例。为了演示我用在线版。第二步找到菜单里的 SQL 导入功能。不同版本的菜单位置略有变化新版本一般是在顶部菜单“整理 Arrange”里找“插入 Insert”再找“高级 Advanced”里的“SQL”如果你用的是旧版桌面客户端通常在“外部数据 Extras”里也有类似入口。点击后会出现一个文本输入框把你的建表语句粘贴进去并选择数据库类型为 MySQL。这里有一个非常重要的细节draw.io 的 SQL 导入不是“翻译器”它不关心你在 SQL 里写的注释和业务逻辑只识别CREATE TABLE、字段类型、PRIMARY KEY和FOREIGN KEY这些结构元素。所以如果你希望导入后自动生成外键连线源 SQL 里必须显式声明外键约束。遇到那种只写了索引、没写外键约束的历史表结构导入后就只能得到一堆没有连线的矩形关系需要你手动补画。导入完成后画布上会自动铺开所有表的矩形。如果你对自动布局不满意可以选中所有图形然后用菜单里的“排列 → 布局”功能选择垂直树、水平树或有机布局。实际经验是几十张表以内用垂直树最容易看超过五十张表什么布局都会乱不如手动分区域整理。最后导出的时候可以根据使用场景选择要发邮件或者放 PPT导出 PNG 或 SVG要嵌入网页截图导出 HTML如果要版本管理直接“文件 → 编辑图表”把这个图的 XML 代码保存进文档仓库里下次打开直接粘贴还原。对这个工具来说ER 图本质上是 XML 数据结构字段名、表名、坐标、连线关系全部都在文本里这一点对程序员特别友好。3.2 实战二用 WWW SQL Designer 反向读取现有 MySQL 库接下来是真正的“浏览器里连库”场景你有一个运行中的 MySQL 数据库想快速生成一张 ER 图。WWW SQL Designer 是三个方案里操作路径最短的。部署方式很简单下载源码放到 Web 服务器目录即可。本地测试时如果机器上有 PHP 环境直接在项目目录下运行php -S localhost:8000然后浏览器打开http://localhost:8000就能进入主界面。如果你需要正式部署到内网服务器建议还是放到 Nginx PHP-FPM 或 Apache mod_php 环境下因为内置服务器性能有限。打开界面之后左侧工具栏第一项就是数据库连接按钮点击后填写数据库地址、用户名、密码、数据库名再选择数据库类型。填好后点 Load它就会读取当前库的所有表结构并在画布上生成对应的表块。这个“Read from database”的功能是我最常用的入口它能自动识别字段名、字段类型、主键和外键关系生成出来的关系和表结构是绑定的不会出现“画了线但改了字段就断掉”的情况。加载完成后你可以手动调整表块位置、折叠/展开字段列表也可以在右侧面板修改字段属性。所有修改都结束后点击工具栏上的“Save”可以保存成一个 XML 项目文件点击“SQL”可以导出完整的 CREATE TABLE 脚本。如果你是想把现有库“导成 SQL 再交给别人建库”这一条链可以满足。不过这里要提醒一下这个项目在 PHP 8 环境下可能会报错我实测在 PHP 8.0 上运行会遇到一些函数废弃的警告页面能开但部分功能异常。最省心的方法是使用 PHP 7.4 版本或者用 Docker 起一个php:7.4-apache容器挂载代码一行命令就能解决环境问题。另外它默认的连接库可能依赖 PDO需要确保 PHP 里已经启用pdo_mysql扩展。3.3 实战三用 SchemaSpy 一行命令生成可发布的 Web 版 ER 文档SchemaSpy 是那种“第一次跑通之后后面每次都在吃老本”的工具。它不需要网页编辑器也没有交互式界面但你只要跑一次生成出来的东西能让整个团队在浏览器里翻阅很久。我先说准备工作你需要一个 Java 运行环境JRE 8 以上基本都行建议用 17 LTS如果希望 ER 图生成 SVG 而不是位图还要安装 Graphviz因为 SchemaSpy 是调用 Graphviz 来渲染关系图的。第三步是准备对应数据库的 JDBC 驱动比如连接 MySQL 8 就需要mysql-connector-java的 jar 包。命令行长这样以 MySQL 为例java -jar schemaSpy.jar \ -t mysql \ -host 127.0.0.1 \ -db demo_db \ -u root \ -p your_password \ -dp /path/to/mysql-connector-java.jar \ -o /var/www/schema_docs跑完以后/var/www/schema_docs目录下会生成 index.html、tables、columns、relationships 等子目录。我一般直接把这个目录软链到 Nginx 的站点根目录或者用 Python 起个临时服务先看一眼效果cd /var/www/schema_docs python3 -m http.server 8080浏览器打开http://localhost:8080你会看到一个带导航栏的数据库文档站左侧是表列表首页有表数量、字段数量、关系数量统计点进每张表能看到字段类型、是否主键、是否 nullable、索引和注释。页面顶部的“Relationships”标签页里就是解析出来的 ER 图支持按表筛选、缩放和点选高亮。这里有个非常适用的场景你手里有一个老系统表有一两百张DBA 也说不清哪些表之间有外键关系。用 SchemaSpy 扫一遍它会根据外键约束自动画出关系图哪些表是“孤岛”一清二楚。虽然它不能编辑但在“摸清家底”这件事上效率比手工画图高出一个量级。3.4 我在实际项目里是怎么选型的工具各有脾气我在不同季度做的项目里选型思路也不太一样。如果只是个人快速画一张评审图、或者给博客配图draw.io 永远是最稳妥的选择因为在线版零成本、功能兜底能力强。如果团队已经有 MySQL 库需要把现有结构“画出来给新人讲”并且公司内网可以部署 PHP 服务我会优先考虑 WWW SQL Designer它加载数据库的速度比手工建表快太多。如果是长期维护的系统数据库结构会频繁变更我建议把 SchemaSpy 加入 CI每次构建时重新生成一次 HTML 文档。这样团队里的后端、前端、测试、运维看到的永远是最新的表结构不用反复在群里喊“谁有最新的 ER 图发我一份”。很多人第一次用 SchemaSpy 时只觉得它“生成了一堆网页”但真正把它嵌入自动化流程之后才会发现这堆网页比很多花哨的设计工具值钱得多。4. 踩坑实录中文乱码、卡顿、多人协作怎么破4.1 中文注释乱码和字符集问题画 ER 图最影响体验的就是中文乱码。字段名用英文还好表的注释、字段注释如果显示成一堆问号整张图基本就废了。先分清是哪个环节出了问题。如果是 draw.io 导入 SQL 后注释乱码大概率是源 SQL 文件本身不是 UTF-8 编码或者缺少DEFAULT CHARSETutf8mb4这样的建表声明。建议第一步先确认 SQL 文件编码用 VS Code 打开看看右下角如果不是 UTF-8先转码再导入。第二步在建表语句中显式给表加注释给字段加COMMENTdraw.io 会把这些信息显示在图形上。如果是 WWW SQL Designer 从数据库读取后乱码问题通常出在连接字符集。你需要确保 PHP 连接数据库时设置了 UTF-8老版本工具可能默认不设置连接编码导致读取回来直接乱码。此时需要在 PHP 代码或者初始化脚本中找到连接字符串部分手动加上charsetutf8mb4。如果项目里封装了 mysqli也要确认set_charset被调用。如果是 SchemaSpy则需要在 JDBC URL 上附带字符集参数。不同数据库驱动写法不一样MySQL 是在命令行传入连接属性或者在-connprops参数里指定useUnicodetruecharacterEncodingUTF-8。不设置的话最终 HTML 里的注释很可能是乱码而且因为是静态页面你还不好直接全局替换。4.2 表特别多时浏览器卡顿怎么办画出上百张表之后几乎所有基于浏览器的 ER 图工具都会开始卡顿。这是 Web 端方案很难回避的限制毕竟浏览器 DOM 操作不是专业图形引擎。我自己的做法是“拆”。如果你要展示的是整个订单域有三四百张表不要指望在一张图里全部铺开。draw.io 支持多层或多页画布可以把概念模型、逻辑模型、物理模型分开WWW SQL Designer 可以只连接到指定的库或前缀表比如只加载orders_开头的表SchemaSpy 则可以用-schema参数指定只生成某一个 schema 的文档。另外一个很值得注意的技巧是在画布上永远只展示核心表细节表的信息用链接或文档补充。ER 图存在的意义是让人看懂关系不是把数据库里的每张表都搬到图上。你要是把一百张表堆在一张图里对方打开第一眼是震撼第二眼就是“这我怎么看”。适当删减反而让沟通更高效。4.3 多人同时编辑的协作方案很多团队想用 Web 工具解决“多人编辑同一张 ER 图”的问题。坦白说这三款工具里真正适合多人实时协作的只有 draw.io 的云存储方案。draw.io 可以对接 GitHub、GitLab、OneDrive、Google Drive多人同时打开同一份文件时会有锁定或冲突提示虽然不是传统意义上的“实时在线协作文档”但已经足够日常协作使用。WWW SQL Designer 保存的是 XML 文件你可以把它丢进 Git 仓库管理但它的 XML 不太适合多人同时编辑因为两个人在不同浏览器里同时保存会相互覆盖。合理用法是把它当作“单机工具但文件入库”谁要改就拉下来改完提交走代码评审流程。SchemaSpy 不涉及编辑所以协作问题不存在所有人都只看一份最新生成的静态文档。我觉得这个反而是最舒服的状态——不需要给每个人都装画图工具你只要保证生成任务在需要时跑一遍即可。4.4 怎么把 ER 图和现有开发流程串起来最后聊一个容易被忽略的点ER 图工具应该服务于开发流程而不是反过来成为流程负担。我的建议是把数据库 DDL 当作唯一的事实来源ER 图只是这份 DDL 的可视化表达。也就是说任何工具生成的图都只是一种“投影”真正值得维护进代码库的是建表脚本而不是某个图形工具的工程文件。顺着这个思路推荐一个实践路径数据库变更以迁移脚本提交到 Git触发 CI 后调用 SchemaSpy 重新生成 HTML 文档再由脚本自动发布到内网文档站点。这样每次表结构变了大家看到的最新 ER 图也会跟着变没有任何人是靠手动截图去同步的。draw.io 的 XML 文件也可以放 Git但它更适合在前期设计评审阶段使用进入开发期之后它的频率会明显降低。如果你只是在做一个数据库课程设计不需要这么重。把 draw.io 导出的 DDL 保存成 .sql 文件再配合画图时导出的 PNG 放入课程设计报告就是一个完整的闭合。甚至可以直接用 WWW SQL Designer 先画草稿、导出 SQL、再去数据库里执行省掉手写建表语句的时间。这些工具看着不同本质上都在帮你把“数据库结构”从抽象概念变成可视化信息用对场景才能真正提升效率。每次我向别人推荐工具时都会强调一句话画图工具永远替代不了你对业务关系的理解。工具能帮你把字段列出来、把线连起来但它不会告诉你为什么用户表和订单表是一对多关系也不会替你判断要不要冗余一个字段。最理想的状态是你先把表之间的关系在脑子里想清楚再用工具把脑海里的结构快速落到画布上。做到这一步选择哪款工具其实都是对的。