主键和外键是 SQL 里最基础也最容易“会用但说不清”的约束。很多人建表的时候加个 PRIMARY KEY再写个 FOREIGN KEY觉得能跑就行直到某天插入数据报错、删数据卡住、批量同步数据对不齐才开始理解这两个约束到底在替你做什么。这篇文章不绕弯子直接拆主键和外键。适合三类人看刚学 SQL 的初学者想把表结构设计得更严谨的开发以及在维护老系统时需要改表加约束的同学。最值得关注的不是怎么敲语法而是“数据库管理系统为什么需要约束”“约束在什么场景下真正发挥价值”“报错之后怎么快速定位”。理解这三层主键和外键才算真正掌握。1. 先搞清楚约束到底在解决什么问题1.1 没有约束的时候表里会发生什么先看一个最简单的场景。假设你的系统里有一张用户表每个用户有一个用户编号。如果没有约束这张表可能出现两种情况两条记录的用户编号相同或者用户编号为空。从应用层看这未必会马上报错。用户编号重复只是查询的时候会多返回一行用户编号为空也只是导出数据的时候多几个空值。但问题会累积。当这张表关联订单表、日志表、权限表之后重复的用户编号会让关联查询出现一对多甚至多对多的结果空值会让外键关联直接失效。到这个时候你面对的不是一条报错而是一堆对不上的数据。数据库管理系统里的约束本质上是把“数据必须满足的规则”下沉到数据库层而不是依赖每个开发人员写代码时自觉遵守。主键和外键就是其中最常用的两条规则。1.2 主键管“表内唯一”外键管“表间一致”主键和外键的职责可以简单记成两句话主键保证一张表内部每一行都能被唯一识别。外键保证一张表里引用的数据在主表里确实存在而且删除主表数据时不会被“孤儿数据”破坏关联。这两条规则合在一起解决的就是数据的一致性和完整性。一致性是说数据不矛盾完整性是说数据不缺、不悬空。没有这两类约束数据库管理系统仍然能存数据但它不保证你存进去的数据是有意义的。很多初学者容易有一个误区主键和外键是“数据库性能工具”。实际上它们本质上是“数据质量工具”。它们不会让查询变快恰恰相反约束会带来写入检查的开销。它们的价值在于让数据质量可控索引才是解决性能问题的设计。1.3 约束在什么时候真正有价值约束发挥最大价值的场景是多人协作和系统长期迭代。单人开发小项目时你清楚自己写了什么数据约束看起来像是多余的。但一旦多人协作不同人维护不同的表A 同学往订单表里插入了 user_id100 的订单但用户表里根本没有 100 号用户B 同学做关联查询时就会查出一堆空行。没有外键约束这种问题只能靠人对数据、对业务流程去发现成本非常高。系统长期迭代也一样。业务层代码可以重构接口可以换但存量数据不会自动变干净。提前把主键和外键约束设计好等于给数据层加了一道长期有效的防线比任何文档和规定都可靠。2. 主键约束非空、唯一、一行一个身份2.1 主键的两个硬性条件主键PRIMARY KEY在标准 SQL 里有两个硬性条件非空NOT NULL和唯一UNIQUE。合起来理解就是主键列上的值既不能空着也不能重复。“非空”和“唯一”这两个条件一定要分开记。很多初学者只记住了唯一忘了非空。后果是你可以插入多条 NULL 值因为数据库里 NULL 和 NULL 不相等UNIQUE 约束不会阻止 NULL 重复。如果主键列允许 NULL你仍然可能插入多条没有编号的记录主键的“唯一识别一行”能力就被破坏了。所以标准 SQL 要求主键列默认具备 NOT NULL 语义。在 MySQL、SQL Server、PostgreSQL、Oracle 这些常见数据库管理系统里定义列级主键或表级主键后该列自动带非空约束。如果建表时主键列没有显式写 NOT NULL数据库引擎也会按主键规则处理。2.2 创建主键的三类常见写法在标准 SQL 里创建主键有三种常见写法。第一种在列定义时直接加 PRIMARY KEYCREATE TABLE users ( user_id INT PRIMARY KEY, user_name VARCHAR(50) NOT NULL );这种写法适合单列主键最简洁。它既是列级约束也隐式创建了主键索引。第二种在表定义末尾加 PRIMARY KEY表级约束CREATE TABLE users ( user_id INT, user_name VARCHAR(50) NOT NULL, PRIMARY KEY (user_id) );这种写法适合需要给主键命名或者主键由多列组成的情况。第三种使用 ALTER TABLE 给已有表添加主键ALTER TABLE users ADD CONSTRAINT pk_users_user_id PRIMARY KEY (user_id);第三种方式在维护旧表时很常用。但要注意如果已有数据里存在空值或重复值添加主键约束会失败。所以给存量表加主键之前一定要先做一次数据清洗。2.3 复合主键多列组合作唯一有时候单列不能唯一识别一行。比如一个学生选课表同一门课里同一个学生只会选一次但学生 ID 在课程表中会重复课程 ID 在学生记录中也会重复。这时需要用 (student_id, course_id) 两列组合作为主键这就是复合主键。CREATE TABLE student_course ( student_id INT, course_id INT, selected_date DATE, PRIMARY KEY (student_id, course_id) );复合主键的“唯一”是组合唯一不是每一列单独唯一。student_id 和 course_id 都可以重复但是两个值的组合不能重复。比如 (1, 101) 只能出现一次(1, 102) 可以出现(2, 101) 也可以出现。使用复合主键要注意两点一是作为外键被引用时会比较麻烦引用它的表需要包含全部主键列二是复合主键会导致索引体积变大尤其是在大数据量场景下。很多设计规范建议优先使用单列代理主键比如自增 ID复杂唯一关系用 UNIQUE 约束去保证而不是硬做复合主键。2.4 主键设计里的常见误区第一个误区是“主键必须用自增整数”。自增整数确实是最常见的选择但不是唯一选择。业务身份证号、业务单号、UUID都可以作为主键。关键是满足“非空、唯一、稳定不变”三个条件。只要满足就可以做主键。第二个误区是“主键列不能参与业务”。这个说法太绝对。如果业务本身就有天然唯一的字段比如订单号、支付流水号直接用它做主键是没问题的。代理主键更多是为了避免业务字段规则变化时影响关联表并不存在“必须完全脱离业务”的硬性要求。第三个误区是“给自增主键加唯一索引会多余”。如果某张表已经有自增主键业务上还要求手机号唯一那么手机号列仍然要加 UNIQUE 约束。主键唯一管的是主键列本身管不了其他业务字段是否重复。把唯一性约束用错位置是很多重复数据产生的根源。3. 外键约束让表间关系“有据可查”3.1 外键在存储层面到底做了什么外键FOREIGN KEY解决的核心问题是引用完整性。它的工作机制就是在从表子表的某列或某几列上声明“这里的值必须来自某张主表父表的主键列或唯一列”。数据库管理系统在每次插入或更新从表数据时会自动检查当前值是否在主表目标列中存在。如果主表里没有对应值插入或更新被拒绝。举个例子CREATE TABLE orders ( order_id INT PRIMARY KEY, user_id INT, order_amount DECIMAL(10,2), CONSTRAINT fk_orders_user FOREIGN KEY (user_id) REFERENCES users(user_id) );这条语句里有几个关键信息CONSTRAINT 给外键取了一个名字fk_orders_user方便后续维护和查看报错来源。FOREIGN KEY (user_id) 表示 orders 表里的 user_id 列是外键。REFERENCES users(user_id) 表示它参考的是 users 表的 user_id 列而且该列必须在 users 表里是主键或唯一键。外键并不要求从表的列名和主表列名一致。这里是“值语义”做关联不是“列名相同”做关联。列名叫 user_id 还是 buyer_id 都可以只要是同一个业务含义、同一个数据类型并且值存在于主表被引用列内。3.2 创建外键的几种方式外键可以在建表时一起创建也可以之后通过 ALTER TABLE 添加。建表时创建CREATE TABLE orders ( order_id INT PRIMARY KEY, user_id INT, order_amount DECIMAL(10,2), CONSTRAINT fk_orders_user FOREIGN KEY (user_id) REFERENCES users(user_id) );之后添加ALTER TABLE orders ADD CONSTRAINT fk_orders_user FOREIGN KEY (user_id) REFERENCES users(user_id);添加外键时有一个前置条件orders 表里不能有 users 表不存在的 user_id 值。如果表里已经有一堆“悬空”的用户编号外键约束会直接创建失败。这跟给存量表加主键是同一个道理——约束是对现存数据的一次体检体检不过约束就建不起来。3.3 外键动作主表删除或更新时怎么办外键约束里最值得深究的部分是 ON DELETE 和 ON UPDATE。它定义的是当主表的记录被删除或主键值被修改时从表里关联的数据怎么办。常见选项有四个NO ACTION / RESTRICT默认行为拒绝删除或修改主表被引用的记录。CASCADE级联操作。主表删除时从表关联记录也自动删除主表更新主键值时从表外键值同步更新。SET NULL主表记录删除或主键值变化后从表外键列被置为 NULL。前提是从表外键列允许 NULL。SET DEFAULT主表记录删除或主键值变化后从表外键列被设置为默认值。前提是列有默认值定义。实际工作中我见过最多的是 RESTRICT 和 CASCADE。SET NULL 在某些场景也很实用下面分别说。RESTRICT 最适合强烈依赖的场景。比如用户和订单如果用户被删除后订单没有意义你希望系统直接禁止删除用户让业务层先处理订单。RESTRICT 的作用就是保护“有关联记录时不能删主表”这条规则。CASCADE 适合父子归属明确的场景。比如博客系统里的文章和评论评论必须从属于某篇文章。删除文章时评论没有保留价值可以自动一起删。CREATE TABLE comments ( comment_id INT PRIMARY KEY, article_id INT, content TEXT, CONSTRAINT fk_comments_article FOREIGN KEY (article_id) REFERENCES articles(article_id) ON DELETE CASCADE );SET NULL 适合“关联关系断了但子记录仍要保留”的场景。比如员工表被删除后离职员工的请假记录还应该保留只是不再关联到具体员工。这个场景里外键列就应该允许 NULL并设置 ON DELETE SET NULL。这里要特别提醒CASCADE 虽然方便但会隐藏数据删除的规模。一条主表记录可能引发大量从表记录被连带删除在高并发系统里大批量级联删除可能会导致锁竞争和事务超时。所以 CASCADE 不是越多越好而是要看业务是否真正接受“联动消失”。3.4 自引用外键树形结构场景外键还可以引用同一张表的主键这叫自引用外键。经典的场景是员工表的上级关系或者商品分类表的父子关系。CREATE TABLE employee ( emp_id INT PRIMARY KEY, emp_name VARCHAR(50) NOT NULL, manager_id INT, CONSTRAINT fk_employee_manager FOREIGN KEY (manager_id) REFERENCES employee(emp_id) );自引用外键的注意点经理manager_id本身也是员工所以插入时首先要保证经理记录已经存在否则会违反外键约束。这会让初始化数据变得麻烦——创建一张部门表时没有经理员工也无法插入。常见处理方式是把最高层管理者的 manager_id 设为 NULL或者先插入层级最高的记录再逐层向下插入。如果设置了 ON DELETE还要额外考虑“删掉经理后下属怎么处理”的问题。4. 组合使用从建表到批量操作的正确顺序4.1 一个学生选课的例子只看主键和外键各自的语法很容易理解。但真实项目里主键和外键经常是组合使用的。我用一个经典的学生选课场景完整拆一遍。场景有三张表students学生表主键 student_id。courses课程表主键 course_id。student_course选课关系表学生和课程是多对多关系。建表顺序不能乱。先建主表 students 和 courses再建从表 student_course。如果先建 student_course它引用的 students 和 courses 还不存在建表会直接报错。CREATE TABLE students ( student_id INT PRIMARY KEY, student_name VARCHAR(50) NOT NULL ); CREATE TABLE courses ( course_id INT PRIMARY KEY, course_name VARCHAR(100) NOT NULL ); CREATE TABLE student_course ( student_id INT, course_id INT, selected_date DATE, PRIMARY KEY (student_id, course_id), CONSTRAINT fk_sc_student FOREIGN KEY (student_id) REFERENCES students(student_id), CONSTRAINT fk_sc_course FOREIGN KEY (course_id) REFERENCES courses(course_id) );这里 student_course 的主键是复合主键两个外键分别引用两张主表。这个结构同时实现了两层完整性一是选课记录不能重复同一个学生同一门课只能选一次二是选课记录必须关联真实存在的学生和真实存在的课程。4.2 插入数据的先后顺序插入数据时先后顺序一样重要。必须先插入主表数据再插入从表数据。正确顺序INSERT INTO students (student_id, student_name) VALUES (1, 张三); INSERT INTO courses (course_id, course_name) VALUES (101, 数据库基础); INSERT INTO student_course (student_id, course_id, selected_date) VALUES (1, 101, 2025-01-10);如果跳过主表直接插入选课记录INSERT INTO student_course (student_id, course_id, selected_date) VALUES (99, 999, 2025-01-10);数据库会报外键约束错误因为 students 表里没有 student_id99courses 表里也没有 course_id999。这个报错不是数据库“太严格”而是它在防止你制造无意义的悬空数据。4.3 删除数据的先后顺序和影响删除数据时顺序和插入相反。要先删除从表记录再删除主表记录。如果直接删除学生DELETE FROM students WHERE student_id 1;在默认的 NO ACTION / RESTRICT 行为下如果 student_course 表里还有这个学生的选课记录这条删除会失败。你需要先删除选课记录再删除学生DELETE FROM student_course WHERE student_id 1; DELETE FROM students WHERE student_id 1;如果建外键时设置了 ON DELETE CASCADE那么删除学生时数据库会自动删除他在 student_course 里的所有记录。这种设计在“学生注销后所有选课记录没有保留价值”的场景下是合理的但前提是你明确知道级联删除的影响范围。实际维护系统时我一般建议先确认外键动作是什么再决定删除顺序。很多线上删除卡住、删除超时不是 SQL 写错了而是外键动作和业务预期不匹配。5. 常见报错和排查链路5.1 错误提示怎么读主键和外键相关的报错在不同数据库管理系统里提示信息不一样但本质指向差不多。比较典型的几类“Duplicate entry xxx for key PRIMARY”插入的主键值重复违反主键唯一约束。“Column xxx cannot be null”主键列或非空列插入了 NULL。“Cannot add or update a child row: a foreign key constraint fails”外键值在主表中不存在。“Cannot delete or update a parent row: a foreign key constraint fails”删除或更新主表时发现存在引用它的从表记录。“Failed to add the foreign key constraint”建外键失败常见原因是数据类型不匹配或目标列不是唯一键/主键。看到这些提示不要急着怀疑数据库配置。绝大多数情况是数据本身不满足约束条件或者表结构定义的时候引用的列属性不对。5.2 插入失败时的排查顺序插入数据报外键错误时我建议按下述顺序排查。第一步确认主表里有没有对应的主键值。直接用 SELECT 查主表看目标 ID 是否存在。很多时候是数据同步先执行了从表插入主表还没插入导致失败。第二步确认外键列的数据类型和主表被引用列的数据类型一致。类型不一致是最隐蔽的坑。比如主表 user_id 是 INT从表 user_id 是 VARCHAR即使写进去的数字看起来一样数据库也可能因为隐式转换规则不一致而报错。最好的做法是设计表时就统一类型不要依赖数据库隐式转换。第三步确认主表被引用列上是否有主键或唯一键约束。外键必须引用主键列或唯一键列。如果被引用列只是普通索引列建外键时就会失败。第四步确认外键动作是不是把业务场景卡住了。比如外键设置的是 RESTRICT你插入数据时主表记录已存在按理不会失败。但如果主表刚被软删除标记而数据库层面没有软删除概念那么约束检查仍然只看物理记录是否存在软删除标记不影响外键检查。5.3 删除失败时的排查顺序删除主表记录失败通常说明有从表记录还在引用它。先看外键动作。如果是 NO ACTION / RESTRICT必须手动处理从表记录。如果是 CASCADE但也删失败了那要检查是不是级联链条里某个表的触发器、级联限制或锁等待导致的报错。再看从表引用范围。有些表设计时以为只有一张从表会引用主表实际上有多张表都建立了外键。比如删除用户时订单表、日志表、收藏表可能都有自己的外键指向用户表。任何一张表里存在关联记录都会阻断删除。排查时要查所有引用该表的外键关系而不是只盯着一处看。最后看数据量。如果从表中存在大量关联记录级联删除需要长时间持锁事务可能超时。这时不能靠单条 DELETE 硬跑要考虑分批删除或先转移关联数据。5.4 主键外键会不会导致性能问题很多人在博客和论坛里问“主键外键会不会拖慢性能”。我的看法是约束一定会带来写入检查开销但这种开销通常很小尤其在表数据量不大的情况下。真正影响性能的不是约束本身而是表结构设计得非常别扭。典型的例子是外键列没有索引。在 MySQL 的 InnoDB 引擎里外键列如果不手动建立索引系统会自动创建一个索引来加速外键检查。但有些数据库或某些设计模式下外键列的索引缺失会导致删除主表记录时全表扫描从表后果是删除操作极慢。排查性能问题的时候先看执行计划确认外键列是否有合适的索引再考虑是否需要调整约束。很多时候慢不是因为约束复杂而是因为索引缺失或 SQL 本身写得不合适。注意添加主键约束给存量表之前一定要先查数据质量。只要存在一行 NULL 或重复值约束就会创建失败。先把数据洗干净再上约束。6. 哪些场景不建议“无脑加外键”6.1 高并发写入场景外键约束需要数据库管理系统在每次插入、更新、删除时执行引用检查这必然增加锁竞争。在高并发写入场景尤其是订单、库存、消息流水这类大表过度依赖外键可能成为写瓶颈。这并不等于说“高并发就不要保证数据完整性”而是说完整性校验可以放在应用层去完成或者通过异步对账、批处理等方式兜底。你需要权衡的是数据库这边多做一次检查带来的性能损失和应用程序里多做一次校验带来的逻辑复杂度哪个更可控。6.2 分库分表场景一旦做了分库分表外键的“本地检查”能力基本失效。因为关联的数据可能分布在不同的物理库、不同的物理表里数据库层的外键约束无法跨库去验证引用是否存在。强行保留外键会带来分布式事务的复杂度通常不建议这么做。分库分表之后引用完整性更多依靠应用层事务、消息队列、定时任务对账等手段来保证。这个阶段的“主键”仍然是核心因为它是跨库检索和幂等判断的基础。但“外键”的作用会被弱化或者说被转移到业务服务层去实现。6.3 如果不用外键靠什么兜底不用外键不代表数据可以随便写。可以靠三类手段兜底一是应用层校验。插入订单前先查询用户是否存在课程是否存在。缺点是校验逻辑可能散落在多个服务里容易出现漏网之鱼。二是定期清洗和告警。写定时任务检查从表里是否存在“悬空引用”发现异常数据后记录日志、推送告警再人工或半自动修复。三是规范制定。把表名、列名、类型、索引、约束的统一设计写进团队规范在代码评审时作为必查项。很多数据质量问题不是数据库管不了的是需求阶段就没想清楚。在实际项目中我见过不少系统从“加外键”改成“应用层校验 定时对账”后写入性能确实得到提升但前提是团队有完整的测试覆盖和对账机制。如果只是单纯删除外键而不做任何兜底就是拿数据一致性换性能风险极高。7. 实践建议先把单表跑稳再设计关系7.1 学习阶段可以从单表主键开始如果你刚接触数据库管理系统我的建议是先把单表主键理解透非空、唯一、索引、自增、UUID、复合主键这些概念都过一遍。能清楚回答“为什么主键列不能允许 NULL”“为什么主键列自动有索引”之后再进入外键学习。外键学习不要停留在语法层面要亲手建两张表插入几条正常数据再故意插入不存在的引用值观察报错。报错信息是很好的学习材料看多了就有感觉了。7.2 工程落地时先画清楚数据关系在设计表结构时先用纸或画图工具把实体关系画出来有哪些表哪个表是主表哪个是从表一对多还是多对多是强依赖还是弱关联。不要直接开写 CREATE TABLE写完之后再改外键关系成本很高。强依赖关系的表例如订单明细依赖订单头、评论依赖文章建议保留外键。弱关联或纯记录日志类表例如登录日志参考用户 ID既不是强一致要求又可能高频写入可以考虑不加外键改用应用层校验。7.3 维护老系统时先做数据体检如果老系统已经跑了很多年里面全是“悬空数据”“重复数据”此时去加主键和外键约束大概率第一次就会失败。一定要先写几个数据质量查询统计出有哪些 NULL、有哪些重复、有哪些引用不存在导出报告后再决定怎么清洗。清洗数据是另外一个工程问题可能涉及业务确认、备份、分批更新、回滚方案不是加一行约束就能解决的。约束是最后落地的“确认按钮”不是第一道清洗工具。注意我一般建议先跑单表数据质量检查再跑关联数据质量检查。两张报告都干净之后才值得真正去执行 ALTER TABLE 添加约束。7.4 从学习到生产的三步验证方式无论你是自己练项目还是在公司改表我建议按下面三步验证。第一步最小环境验证。用精简表结构、几条样例数据确认主键和外键的基础行为符合预期。第二步批量数据验证。导入几百条、几千条模拟数据测试主键重复、外键悬空、级联删除等场景确认报错信息可读、处理方式可预期。第三步生产预案验证。确认添加约束失败时怎么回滚删除主表数据时怎么人工补偿外键动作变化了对上下游报表、ETL、同步任务有没有影响。这些预案不是数据库知识本身但却是工程落地时最需要关注的部分。把这三步走完再回头看主键和外键你会意识到它们不是“限制”而是数据质量的守护规则。没有限制的系统短期写数据很快长期维护成本会远远超过提前设计约束省下的那点时间。8. 几个值得记住的结论主键和外键是 SQL 数据库管理系统里最基础的完整性机制。主键保证表内每行可唯一识别外键保证表间引用不悬空。它们解决的核心问题是数据质量不是查询性能。创建主键时重点看非空、唯一、索引是否到位。创建外键时重点看被引用列是否唯一、数据类型是否一致、外键动作是否符合业务预期。做增删改时记住先主表后从表、先从表后主表的基本顺序。遇到约束报错先看数据再看参数最后才考虑是不是数据库配置或工具本身的问题。要不要在每一处关系上都加外键取决于业务场景。强一致、强关联、数据量可控的表外键值得保留。高并发、分库分表、纯日志场景外键可以变通为应用层校验加上对账机制。最后留一句实践判断如果一套系统跑了很多年却从没出现悬空数据说明约束或校验做得到位如果经常出问题那要补的不是更多代码而是更明确的数据规则。把主键和外键当作规则来看你的建表思路会清晰很多。