一文讲透主键、外键与约束：从理论到实战，数据库设计的基石
为什么你的数据总是乱七八糟？为什么删个部门还要先删一堆员工？主键和外键就是数据库世界的“身份证”和“契约锁”。今天，我们用最透彻的方式，把这些概念彻底讲明白。
在数据库设计中，主键和外键是最基础也最重要的两个概念。它们不仅是表结构的“骨架”，更是保证数据完整性和一致性的核心机制。很多初学者对它们一知半解，导致设计出来的表冗余、混乱、异常频发。今天，我们就从零开始，把主键、外键及其约束一网打尽。
一、什么是主键（Primary Key）？
1.1 定义
主键是表中用于唯一标识每一行数据的一个列或多个列的组合。它就像每个人的身份证号，在整个表中不能重复，也不能为空。
1.2 主键的特性
- 唯一性：表中任意两行的主键值不能相同。
- 非空性：主键列不能包含 NULL 值。
- 稳定性：主键值一旦确定，不应频繁修改（最好永不修改）。
- 最小性：复合主键的列数应尽可能少。
1.3 主键的创建方式
（1）单列主键
-- 方式1：建表时指定CREATETABLEstudent(idINTPRIMARYKEY,nameVARCHAR(50));-- 方式2：建表后添加ALTERTABLEstudentADDPRIMARYKEY(id);（2）复合主键（联合主键）
CREATETABLEcourse_selection(student_idINT,course_idINT,scoreINT,PRIMARYKEY(student_id,course_id));1.4 主键的常见选择
| 类型 | 示例 | 优点 | 缺点 |
|---|---|---|---|
| 自增整数 | id INT AUTO_INCREMENT | 简单、高效、有序 | 迁移时可能冲突，暴露业务量 |
| UUID | id CHAR(36) | 全局唯一，不暴露信息 | 占用空间大，索引性能差 |
| 业务字段 | id_number VARCHAR(18) | 有业务含义 | 可能变化，不易稳定 |
| 雪花算法 | id BIGINT | 分布式唯一，趋势递增 | 实现稍复杂 |
建议：在大多数场景下，使用自增整数或雪花算法ID作为代理主键，避免使用业务字段作为主键。
二、什么是外键（Foreign Key）？
2.1 定义
外键是一个表中的列，它引用另一个表的主键（或唯一键）。外键用于在两个表之间建立关联，并维护引用完整性。
2.2 外键的作用
- 建立表间联系：比如学生表中的
class_id引用班级表的id。 - 保证数据一致性：防止出现“孤儿数据”（如一个学生被分配到不存在的班级）。
- 级联操作：当主表记录更新或删除时，自动处理从表相关记录。
2.3 外键的创建方式
-- 建表时指定外键CREATETABLEstudent(idINTPRIMARYKEY,nameVARCHAR(50),class_idINT,FOREIGNKEY(class_id)REFERENCESclass(id));-- 建表后添加外键ALTERTABLEstudentADDCONSTRAINTfk_student_classFOREIGNKEY(class_id)REFERENCESclass(id);三、外键约束的四大动作
当主表（被引用表）的记录被更新或删除时，外键约束可以定义从表的行为。这是外键最强大的功能。
| 动作 | 说明 |
|---|---|
| CASCADE | 主表更新/删除时，从表中的相关记录也同步更新/删除。 |
| SET NULL | 主表更新/删除时，将从表的外键列设置为 NULL。 |
| SET DEFAULT | 主表更新/删除时，将从表的外键列设置为默认值。 |
| RESTRICT | 如果从表有相关记录，禁止主表执行更新/删除操作。 |
| NO ACTION | 与 RESTRICT 类似，但检查时机略有差异（MySQL 中两者等价）。 |
3.1 示例
CREATETABLEclass(idINTPRIMARYKEY,nameVARCHAR(50));CREATETABLEstudent(idINTPRIMARYKEY,nameVARCHAR(50),class_idINT,FOREIGNKEY(class_id)REFERENCESclass(id)ONDELETECASCADE-- 删除班级时，自动删除该班所有学生ONUPDATECASCADE-- 更新班级ID时，自动更新学生表中的class_id);3.2 实际业务中的选择
- CASCADE：适用于“整体-部分”强关联（如订单-订单项）。
- SET NULL：适用于“弱关联”，删除主表后从表记录仍保留但失去关联（如用户注销后，保留其发帖记录但作者设为 NULL）。
- RESTRICT：最常用，防止误删重要数据（如删除部门前必须确保没有员工）。
四、外键约束的规则与限制
4.1 引用规则
- 外键必须引用主表的主键或唯一键。
- 外键列和引用列的数据类型必须完全一致（包括长度、符号）。
- 外键列可以有多个，形成复合外键。
4.2 数据操作限制
- INSERT：插入从表时，外键值必须在主表中存在（除非允许 NULL）。
- UPDATE：修改从表外键值时，新值必须在主表中存在。
- DELETE：删除主表记录时，受外键约束限制（除非定义了级联动作）。
4.3 索引要求
- MySQL 的 InnoDB 引擎要求外键列必须建立索引（否则会自动创建）。这有助于加速外键检查。
五、主键与外键的对比
| 维度 | 主键 | 外键 |
|---|---|---|
| 作用 | 唯一标识一行 | 建立表间关联，维护引用完整性 |
| 唯一性 | 必须唯一 | 通常不唯一（一对多关系） |
| 空值 | 不允许 NULL | 允许 NULL（表示无关联） |
| 个数 | 每表最多一个 | 可以有多个 |
| 索引 | 自动创建聚簇索引 | 建议创建索引（InnoDB 自动创建） |
| 约束 | 实体完整性 | 参照完整性 |
六、实战案例：学生-班级-课程系统
我们设计一个完整的数据库，演示主键和外键的使用。
6.1 表结构
-- 班级表（主表）CREATETABLEclass(idINTPRIMARYKEYAUTO_INCREMENT,nameVARCHAR(50)NOTNULLUNIQUE,teacherVARCHAR(50));-- 学生表（子表，引用班级）CREATETABLEstudent(idINTPRIMARYKEYAUTO_INCREMENT,nameVARCHAR(50)NOTNULL,class_idINT,FOREIGNKEY(class_id)REFERENCESclass(id)ONDELETERESTRICT-- 有学生的班级不能删除ONUPDATECASCADE);-- 课程表CREATETABLEcourse(idINTPRIMARYKEYAUTO_INCREMENT,nameVARCHAR(50)NOTNULL);-- 选课表（多对多关系，复合外键）CREATETABLEselection(student_idINT,course_idINT,scoreINT,PRIMARYKEY(student_id,course_id),FOREIGNKEY(student_id)REFERENCESstudent(id)ONDELETECASCADE,FOREIGNKEY(course_id)REFERENCEScourse(id)ONDELETERESTRICT);6.2 测试约束
-- 1. 插入班级INSERTINTOclass(name,teacher)VALUES('计算机1班','王老师');-- 2. 插入学生（外键有效）INSERTINTOstudent(name,class_id)VALUES('张三',1);-- 成功-- 3. 尝试插入不存在的班级INSERTINTOstudent(name,class_id)VALUES('李四',99);-- 错误：外键约束失败-- 4. 尝试删除有学生的班级DELETEFROMclassWHEREid=1;-- 错误：RESTRICT 阻止-- 5. 先删除学生再删除班级DELETEFROMstudentWHEREid=1;DELETEFROMclassWHEREid=1;-- 成功七、外键的优缺点与使用争议
7.1 优点
- 保证数据一致性：数据库层面强制引用完整性，避免脏数据。
- 简化应用逻辑：应用层无需额外检查外键存在性。
- 级联操作方便：一条语句完成主从表联动。
7.2 缺点
- 性能开销：每次 INSERT/UPDATE/DELETE 都需要检查外键约束，影响写入性能。
- 锁竞争：高并发下可能导致死锁。
- 分库分表困难：分布式数据库中跨库外键难以实现。
- 灵活性降低：某些业务需要短暂违反完整性（例如先插从表后插主表），外键会阻止。
7.3 业界观点
- 传统DBA：强烈推荐使用外键，保证数据正确性。
- 互联网大厂：普遍禁用外键，由应用层（如事务脚本）保证数据一致性，以获得更高的并发和扩展性。
- 折中方案：在核心金融、ERP等对一致性要求极高的系统中使用外键；在高并发、分库分表场景下放弃外键。
八、常见面试题
Q1：主键和唯一索引的区别？
A：主键是约束，唯一索引是索引。主键不能为空，一个表只能有一个；唯一索引允许 NULL（但只有一个 NULL），可以有多个。
Q2：外键一定是引用主键吗？
A：可以引用唯一键（即具有 UNIQUE 约束的列），但实践中通常引用主键。
Q3：MySQL 中哪些存储引擎支持外键？
A：InnoDB 支持外键，MyISAM 不支持（因此使用 MyISAM 时无法强制外键约束）。
Q4：级联删除（CASCADE）会有什么问题？
A：可能导致意外大面积删除数据。例如删除一个部门时，所有员工、员工的考勤、绩效等都会连带删除。应谨慎使用。
Q5：可以禁用外键检查吗？
A：可以，MySQL 中使用SET FOREIGN_KEY_CHECKS = 0;临时禁用，用于数据迁移或批量导入。完成后重新启用。
九、最佳实践建议
- 优先使用代理主键（自增或雪花ID），避免业务字段作为主键。
- 外键命名规范：
fk_从表名_主表名，便于维护。 - 合理选择级联动作：通常
ON DELETE RESTRICT是保险做法，CASCADE要三思。 - 外键列必须建立索引（InnoDB 会自动建，但手动确认）。
- 高并发写入场景：考虑放弃外键约束，在应用层通过事务保证一致性。
- 分库分表下：不要使用外键。
十、总结
主键和外键是关系数据库的“骨架”和“锁链”。主键确保了每一行的唯一身份，外键则维系了表与表之间的数据契约。理解并正确使用它们，你的数据库设计就能做到结构清晰、冗余可控、一致性强。
但是，范式不是教条。在实际工程中，我们需要根据业务一致性要求、并发量、扩展性等因素，灵活决定是否使用外键。记住：数据库约束是最后一道防线，但不是唯一防线。
思考题：
- 在分布式数据库或微服务架构下，如何实现类似外键的引用完整性？
- 为什么很多大厂禁止使用外键，却仍在使用自增主键？
欢迎评论区讨论！
如果觉得有帮助，点赞、收藏、转发～
本文首发于 CSDN，未经授权禁止转载。
