开始之前

两张表出现同名字段或 *_id 字段，不代表数据库声明了外键。关系图不应猜测业务含义。本教程用几组小输入区分“没有关系声明”和“输入没有覆盖完整结构”。

边看边操作在 SQL 建表语句转 ER 图 中打开实际工作区
01

复现只有表、没有线

分析下面 SQL。预期两张表、零条关系。这是正确结果，因为 customer_id 只有名字，没有 REFERENCES。

示例
CREATE TABLE customers (id BIGINT PRIMARY KEY);
CREATE TABLE orders (id BIGINT PRIMARY KEY, customer_id BIGINT);
02

识别后置 ALTER TABLE

分析下面版本。预期仍是零条已解析关系，并出现 ALTER 未处理提示。数据库可能支持这个语句，但当前绘图工具不把它合并进前面的表定义。

示例
CREATE TABLE customers (id BIGINT PRIMARY KEY);
CREATE TABLE orders (id BIGINT PRIMARY KEY, customer_id BIGINT);
ALTER TABLE orders ADD CONSTRAINT fk_customer FOREIGN KEY (customer_id) REFERENCES customers(id);
03

在分析副本中整理声明

将确实存在的外键放到 CREATE TABLE 的分析副本里，再重新分析。这个整理仅用于描述已知结构，不是让你重新创建生产表或凭空添加约束。

示例
CREATE TABLE customers (
  id BIGINT PRIMARY KEY,
  name VARCHAR(80) NOT NULL
);
CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  customer_id BIGINT NOT NULL,
  total DECIMAL(10,2),
  FOREIGN KEY (customer_id) REFERENCES customers(id)
);
04

核对目标表是否包含在输入

预期现在有 1 条 orders → customers 关系。若去掉 customers 的建表语句，应看到“引用表未提供”提示；把目标表补回，再确认引用字段存在且名称一致。

schema 和引号导致的名称差异

sales.customers 与 customers 在输入里是不同的名称。检查 CREATE TABLE 与 REFERENCES 是否使用一致的限定形式；带引号的名称还要核对大小写。不要批量去掉 schema 或引号来强行合并本来不同的表。

应用层关联不会自动变成数据库外键

某些系统刻意只在应用层维护关联。此时零条外键不代表系统坏了；可以在外部文档补充业务关系，但不要把推测的连线当成数据库实际约束。

解析范围与数据库验证

工具只在浏览器解析 CREATE TABLE，不连接数据库也不执行 SQL。支持的外键会用于画图；ALTER TABLE、索引和其他未覆盖语句会提示复核，不能据此认为这些约束在数据库中不存在。每次最多 60 张表、1500 个字段，输入不超过 1 MiB。

要点总结
  • *_id 命名不会自动生成外键。
  • ALTER TABLE 未解析与数据库不支持是两回事。
  • 整理分析副本时保留真实结构含义。