外键约束是数据库层强制执行参照完整性的硬性机制，要求InnoDB引擎、主子表字段类型及索引严格匹配，并需根据业务逻辑合理配置ON DELETE/UPDATE行为，同时防范运行期检查关闭导致的约束失效。
外键约束不是“加了就完事”的装饰性语法，它是在数据库层主动拦截非法关联、强制执行业务规则的硬性机制。真正闭环的关键，在于从建表开始就对齐技术条件、匹配业务语义，并持续守住约束有效性。
引擎与表结构必须严格满足硬性前提
外键只在 InnoDB 引擎下生效，MyISAM 完全忽略 FOREIGN KEY 语句。建表时务必显式指定：ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
已有 MyISAM 表需先转换：ALTER TABLE table_name ENGINE=InnoDB;
主表被引用列（如 users.id）必须是 PRIMARY KEY 或 UNIQUE KEY；子表外键列（如 orders.user_id）本身也必须有索引（MySQL 会自动创建，但显式建更可控）。
字段级一致性常被忽视：类型、符号（SIGNED/UNSIGNED）、长度（INT(10) 与 INT(11) 不等价）、字符集（utf8mb4 vs utf8）、排序规则（utf8mb4_0900_as_cs）必须完全一致。任一不匹配都会报错 ERROR 1215 或 errno: 150。
ON DELETE / ON UPDATE 必须按业务生命周期选型
级联行为不是可选项，而是数据归属逻辑的声明：
- ON DELETE CASCADE：适用于强绑定关系，如订单明细依赖订单头、日志条目依赖日志批次。父记录删，子记录必须同步消失。
-
ON DELETE SET NULL：适用于允许“归属丢失”的场景，如员工离职后工单仍需保留，仅清空
assignee_id（该字段需允许 NULL）。 - ON DELETE RESTRICT（默认）：最安全，禁止删除仍有子记录的父记录。适合核心主数据（如用户、产品），由应用层先清理或归档子表再操作。
慎用 CASCADE 在高频更新的父表上——一次 UPDATE 可能触发大量隐式写入，延长事务、扩大锁范围。
警惕运行期约束失效的隐形陷阱
外键检查是会话级开关，默认开启，但极易被人为关闭：
-
SET FOREIGN_KEY_CHECKS = 0;后未恢复，后续所有 DML 都跳过校验； - 批量导入（
LOAD DATA INFILE）脚本为提速常关检查，若中途出错或忘记重开，脏数据已入库； - 跨库引用（
db1.users → db2.orders）在 MySQL 中根本不支持，语法即报错。
建议：上线前用 SELECT @@FOREIGN_KEY_CHECKS; 确认全局状态；关键业务表定期执行 SHOW CREATE TABLE 核对外键定义是否仍在。
外键是兜底，不是替代应用层校验
外键能拦住“不存在的 user_id”，但拦不住“user_id=123 的用户已被冻结，不可下单”。它保障的是参照完整性，而非业务状态合法性。
典型闭环组合是：
– 数据库层：外键 + NOT NULL / CHECK（如订单金额 > 0）；
– 应用层：事务中先查用户状态，再插入订单，失败则回滚。
二者分工明确，缺一不可。
