dbdiagram.io 可通过 SQL DDL 或直连数据库快速生成带主外键、关系线和字段说明的 ER 图，支持 PNG/SVG/SQL 导出；需确保 DDL 中约束完整或数据库权限开放，SVG 嵌入时中文建议改用 PNG。
怎么用 dbdiagram.io 快速导出可协作的 ER 图
直接把数据库结构变成带关系线、字段说明、主外键标注的图，是团队对齐最省力的方式。dbdiagram.io 不需要装客户端，支持从 sql ddl（比如 create table 语句）或主流数据库直连生成，导出 png/svg/sql 多种格式。
实操建议：
- 粘贴 DDL 时，确保每张表的
PRIMARY KEY和FOREIGN KEY定义完整，否则关系线会缺失 - 如果用 PostgreSQL/MySQL 直连，需开启
pg_stat_statements或配置information_schema查询权限，否则部分视图和约束不显示 - 导出 SVG 后可直接嵌入 Confluence 或 Notion，但注意字体渲染：本地没装对应字体时，中文可能变方块——改用 PNG 更稳妥
- 别依赖自动生成的“备注”字段：
COMMENT ON COLUMN在 PostgreSQL 中需显式开启注释提取，MySQL 则默认忽略COMMENT属性
为什么 sqlfluff + eralchemy 比纯手工画图更可靠
靠人眼从几百行 SQL 里找外键、推导层级，容易漏掉隐式关联（比如用字符串匹配代替 JOIN），而 eralchemy 能解析真实执行计划里的依赖链，sqlfluff 则能提前拦截建表语句中违反规范的写法（如缺失 NOT NULL 约束、命名不统一）。
常见错误现象：
-
eralchemy报错AttributeError: 'NoneType' object has no attribute 'name'：通常是某张表的__table_args__里混用了 SQLAlchemy 1.x 和 2.x 的语法 -
sqlfluff对ALTER TABLE ADD CONSTRAINT识别率低：建议把约束定义全写进CREATE TABLE，避免拆分语句 - 生成的图里出现大量交叉线：不是工具问题，而是表之间存在多对多中间表未被正确定义为独立实体——得补上
CREATE TABLE order_product (...)这类语句再重跑
团队共享时，ER 图文件怎么放才不会过期
放在 GitHub README 里截图？下次字段一改就失效。最简单的可持续方案，是把 ER 图生成逻辑固化进 CI 流程，每次 git push 后自动更新。
使用场景与参数差异：
- 用
eralchemy -i "postgresql://..." -o erd.png时，连接串必须带?sslmode=disable（开发环境）或配置.pgpass（生产环境），否则 CI 会卡在密码输入 - 如果数据库有上百张表，加
--include-tables参数限定范围，否则生成的图密密麻麻根本没法看 - Confluence 插件
drawio支持导入.graphml，但eralchemy默认不输出该格式——得加-o erd.graphml -t graphml - 别把生成命令写死在 Makefile 里：不同成员本地数据库端口/用户不同，应统一读取
.env文件中的DB_URL
DDL 脚本里哪些细节会让 ER 图“看起来对、实际错”
外键指向的字段类型不一致、字符集不同、甚至只是大小写拼写偏差（比如 user_id vs USER_ID），都会导致工具判定“无关联”，但业务代码里照样能跑通——这种隐患最难排查。
性能与兼容性影响：
- MySQL 中
VARCHAR(255) CHARSET utf8mb4和VARCHAR(255) CHARSET utf8被视为不同字段类型，eralchemy不会画连线 - PostgreSQL 的域类型（
CREATE DOMAIN phone_number AS TEXT）会被识别为TEXT，但外键引用该域时，工具可能无法回溯原始定义 - SQL Server 的
IDENTITY列若没配SEED和INCREMENT，某些解析器会跳过主键标记 - 所有工具都忽略触发器和存储过程里的隐式关联——这类逻辑必须单独文档化，不能指望 ER 图覆盖
真正难的不是画出来，是让图里每条线都经得起 SELECT 验证。字段名拼写、类型精度、字符集、约束可见性，这些地方差一点，协作时就得多开三次会来对齐。
