DBeaver 不直接创建外键，而是生成并执行 ALTER TABLE 语句，真正生效依赖数据库引擎（如 InnoDB）及前提条件：两表须为 InnoDB、外键与被引用列均需匹配索引、数据类型与字符集严格一致。
直接说结论：DBeaver 本身不“建外键”，它只是帮你生成并执行符合 MySQL（或其他数据库）要求的 ALTER TABLE ... ADD FOREIGN KEY 语句；真正起作用的是数据库引擎（比如 InnoDB），且必须满足前提条件，否则会静默失败或报错。
为什么点“新建外键约束”没反应或报错
常见现象是：在表设计视图 → “约束”页点击“新建外键约束”，填完字段后保存，结果提示“无法保存更改”或弹出 SQL 错误，比如 ERROR 1005 (HY000): Can't create table 或 ERROR 1215 (HY000): Cannot add foreign key constraint。
根本原因不是 DBeaver 问题，而是数据库层面卡住了。最容易被忽略的三点：
- 两张表都必须是
InnoDB引擎（MyISAM不支持外键） - 外键列（如
dept_id）和被引用列（如dept.id）必须有**完全匹配的索引**——InnoDB 要求被引用列必须是主键或有唯一索引，而外键列自己也**必须已建索引**（DBeaver 8.0+ 会在添加外键时自动加，但老版本或手动删过索引就会漏） - 数据类型必须严格兼容：
TINYINT和INT可以，但VARCHAR(20)和CHAR(20)在某些排序规则下可能不认；字符集和校对规则（collation）也得一致
用图形界面加外键的实际步骤（MySQL 场景）
这不是点点就完的事，关键动作要到位：
- 先确认目标表（子表）和主表都用的是
InnoDB：右键表 → “编辑表” → 查看“引擎”字段，不是就改：ALTER TABLE xxx ENGINE = InnoDB - 确保主表被引用字段是主键或有唯一索引（比如
dept(id)是主键，OK） - 确保子表外键字段已有索引：如果还没建，先在子表设计视图 → “索引”页 → 新建一个单列索引，选中该字段（如
dept_id）→ 保存 - 再进子表 → “约束”页 → “新建外键约束” → 填写：
- 外键字段：选
dept_id - 主表：选
dept - 主表字段：选
id - ON DELETE / ON UPDATE：按业务选，开发环境建议先用
RESTRICT防误删
- 外键字段：选
- 点保存，DBeaver 会执行类似这样的语句：
ALTER TABLE emp ADD CONSTRAINT fk_emp_dept_id FOREIGN KEY (dept_id) REFERENCES dept(id) ON DELETE RESTRICT
什么时候该用 SQL 手动写，而不是图形界面
图形界面方便，但掩盖细节；遇到以下情况，必须切到 SQL 编辑器手写：
- 要给已存在的外键改名（图形界面不提供 rename 功能）：
ALTER TABLE emp DROP FOREIGN KEY old_name; ALTER TABLE emp ADD CONSTRAINT new_name FOREIGN KEY (dept_id) REFERENCES dept(id); - 主表字段不是主键，而是带
UNIQUE约束的字段——图形界面有时识别不到，但 SQL 明确写就支持 - 需要设置复合外键（两个字段一起引用另一张表的两个字段），图形界面操作容易漏字段映射
- 想跳过 DBeaver 的自动索引逻辑（比如你已经明确建好联合索引），避免它多建一个冗余单列索引影响性能
虚拟外键不是真外键，别当真用
右键表能看到“编辑虚拟外键”，这个只影响 DBeaver 内部功能（比如 ER 图连线、双击字段跳转关联数据），**不会发任何 SQL 到数据库，也不参与约束检查**。
如果你看到 ER 图里有线连着，但 SELECT * FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'emp' 查不到记录，说明只是虚拟的。上线前务必确认物理外键真实存在，否则数据一致性完全靠人肉维护。
最易被忽略的一点：外键会拖慢大批量 INSERT 或 UPDATE，尤其在未加索引的外键列上做 JOIN 查询时，优化器可能弃用索引。上线前记得在真实数据量下压测外键开销。
