主键与外键的区别：从数据库约束到分布式架构的工程实践

1. 从一次重复下单事故说起主键和外键各自在防什么每次看到有人问主键和外键有什么区别我都想先扔一个事故现场出来。背定义谁都会真正明白自己为什么要用这两个东西的人并不多。上周我就遇到一个典型case。一个老系统里订单表压根没建主键业务端为了防重复下单用先查订单是否存在不存在就插入的逻辑做幂等。平时没毛病但活动大促流量一上来两个并发请求同时查不到订单同时走insert订单表里就多了一条一模一样的脏数据。数据库层没有任何机制能拦这件事因为一模一样的两行在数据库看来根本不违法。后来怎么解决的加上主键自增列再把用户ID商品SKU下单时间做成唯一索引问题当场消失。这件事说明一个很多人忽略的事实主键不是给表加个id这么简单它是数据库判断两行数据是否相同的依据也是InnoDB组织整张表存储的锚点。1.1 没有主键的表连同一行都说不清你可以把主键理解成身份证号。一个人可以改名、换住址、换手机号但身份证号不能变它是在整个系统中唯一标识一个人的关键属性。对于MySQL表来说主键就是每一行数据的身份标识。没有主键会发生什么在MyISAM引擎里每一行都是独立存储的系统只能靠物理位置来区分它们在InnoDB里表默认会有一个隐藏的rowid作为内部行标识。问题是这个内部标识对应用完全不可见你无法通过一条where条件精确命中某一行update和delete也只能靠碰运气去匹配。更严重的是数据一致性问题会从源头失控——就像刚才说的重复下单数据库根本不认为它是重复的。主键的核心价值是给每一行提供确定性。要么是业务自然键比如身份证号、学号要么是代理键比如自增id。不管哪种一旦确定这条记录在整张表里就是唯一可寻址的。1.2 外键防的是另一种错引用关系被破坏主键解决的是行内身份问题外键解决的是行间关系问题。举个例子。订单表里有一个user_id它指向用户表的主键id。如果业务代码存在bug往订单表里插入了一个user_id9999的记录而用户表里根本没有这个用户理论上这就算非法数据。外键的作用就是数据库帮你拦住这类操作——在插入或更新时检查你引用的值在父表里必须真实存在。外键的全称是外键约束它由三部分组成子表引用方、父表被引用方、引用列。订单表是子表用户表是父表user_id是外键列。只要这个约束存在数据库就会强制执行引用完整性规则。注意外键和主键有个本质区别主键是必须存在的设计每张表都应该有外键是可选的设计建不建完全看你的业务策略。这也直接引出了后面要讲的工程界争论——到底该不该用外键。1.3 一个模型把两者放一起看把用户和订单放在同一个模型里看就清晰了用户表usersid是主键唯一标识一个用户。订单表ordersid自己的主键user_id是外键引用users.id。主键保障users表里的每一行都是独立且可识别的。外键保障orders表里所有user_id都能在users表里找到对应记录。主键是对内的约束保证数据在表内不乱外键是对外的约束保证数据在表间不乱。这是理解两者区别的第一层也是最核心的一层。2. 建表SQL拆解主键与外键的语法和底层的索引真相概念清楚了接下来看建表SQL。很多Java开发者会用ORM工具自动建表反而对原生SQL生疏了这里完整拆一遍。2.1 主键的三种定义方式第一种列级约束最简单CREATE TABLE users ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL, email VARCHAR(100) );第二种表级约束适合复合主键CREATE TABLE order_items ( order_id BIGINT NOT NULL, product_id BIGINT NOT NULL, quantity INT NOT NULL, PRIMARY KEY (order_id, product_id) );第三种通过ALTER TABLE补加ALTER TABLE users ADD PRIMARY KEY (id);有一点值得强调复合主键并不是多个主键。一张表只能有一个主键但这个主键可以由多列共同组成。很多面试者会说一张表可以有两个主键这是错的。复合主键的整体才是一个主键它的唯一性取决于所有列的联合值。2.2 外键约束的完整语法外键约束的标准写法是CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, total_amount DECIMAL(10,2) NOT NULL, CONSTRAINT fk_orders_user FOREIGN KEY (user_id) REFERENCES users(id) );拆开解释CONSTRAINT fk_orders_user给约束起个名字方便以后删除或查看。FOREIGN KEY (user_id)指定子表中哪一列是外键列。REFERENCES users(id)指定引用哪张父表的哪一列。父表这一列必须有索引通常就是父表主键。后面还可以跟ON DELETE和ON UPDATE控制父表记录被删、被改时子表的行为下一章单独讲。在建表之后补加外键也常见尤其接手老项目时ALTER TABLE orders ADD CONSTRAINT fk_orders_user FOREIGN KEY (user_id) REFERENCES users(id);删除外键约束ALTER TABLE orders DROP FOREIGN KEY fk_orders_user;这里有个细节要注意如果外键列已经有数据且数据中存在在父表里找不到对应值的脏数据那么添加外键约束会直接失败。遇到过很多次加约束报错一查全是历史数据问题。所以加外键前一定先做一次脏数据扫描。2.3 为什么InnoDB会为外键自动建索引这是面试中很容易被问到、但很多人没深究的细节。InnoDB在创建外键约束时如果外键列上还没有索引会自动创建一个普通索引。原因是当父表更新或删除记录时数据库需要反向检查子表中有没有引用该记录的行的这一步本质上是拿父表的旧值去子表里查而查询必须走索引否则就是全表扫描性能无法接受。这也是为什么你查看SHOW INDEX FROM orders时会发现除了主键索引还多了一个名为fk_orders_user的索引即使你当初没显式创建。另外InnoDB是聚簇索引组织表主键直接决定了数据在磁盘上的物理排列顺序。每张InnoDB表只能有一个聚簇索引主键就是它。如果没有主键InnoDB会选择第一个非空的唯一索引作为聚簇索引如果连唯一索引都没有就生成一个隐藏的rowid。这个隐藏rowid对应用不可见也会导致数据行无法被稳定引用。所以InnoDB表必须要有主键这句话是有底层原理支撑的不是规范强迫症。3. 主键和外键的五个核心区别对比表加三个易错细节理论聊完了直接上干货对比。3.1 一张表看清五个维度对比维度主键外键唯一性必须唯一不要求唯一可以重复是否允许NULL不允许允许NULL表示无引用关系每张表数量只能有一个允许复合可以有多个约束方向约束本表行记录的身份约束本表列与父表列的引用关系索引性质自动创建聚簇索引自动创建普通索引辅助索引删除影响影响表的数据组织方式只影响约束检查不影响数据本身最容易被忽略的是NULL这一行。外键列允许NULL而且NULL的含义是这条记录没有引用任何父表记录数据库不会去校验NULL。这个特性在业务上很有用比如订单表的优惠券ID外键没有使用优惠券时就是NULL完全合法。但主键绝对不能NULL因为一行数据连身份都没有数据库无法处理。3.2 复合主键和唯一键两个容易被绕晕的概念复合主键上面提过再补充一个实际案例。比如课程选课表用student_id course_id做复合主键表示一个学生只能选同一门课一次。这个设计在业务上很常见。但要注意一旦用了复合主键所有引用这张表的外键也要带上全部主键列否则引用不了这在真实项目中会让SQL变得很繁琐。所以很多团队宁可加一个自增id当主键再用UNIQUE KEY (student_id, course_id)做业务唯一性约束。这里就牵出另一个高频率考点主键和唯一键UNIQUE KEY的区别。主键不能为NULL唯一键可以有一个或多个NULL值。主键是聚簇索引唯一键是辅助索引。一张表只能有一个主键但可以有多个唯一键。业务上经常需要主键管身份唯一键管业务的组合。比如用户表的主键是自增id但username必须唯一就再加一个唯一键。这就是为什么说主键不等于唯一键唯一键也不一定能当主键用。3.3 ER图、Navicat和面试题里的主键外键表示说到这里顺便回应一下热搜词里的几个高频搜索。画ER图时主键通常在属性下面加下划线外键一般用虚线边框或FK标注不同工具表示方式略有差异但核心都是区分身份属性和引用属性。用Navicat给表添加外键操作路径是右键表 - 设计表 - 外键标签页 - 填写字段名、被引用库表、被引用字段并选择删除/更新时的动作规则。图形化工具降低了门槛但也让很多人忽略了背后的语义看到外键两个就无脑加这是不推荐的。面试题里常见的表示法是给你一张订单表和用户表问你订单里的user_id是主键还是外键。答案是外键只要它不是本表唯一标识而是引用另一个表的主键它就是外键。这个判断标准要记牢不是看字段名而是看它在本表中扮演的角色。4. 外键级联操作ON DELETE / ON UPDATE 方便背后的风险外键约束里最容易引起事故的是级联动作。建表时可以指定父表记录被删除或更新时子表怎么办。MySQL提供了四种规则CASCADE、SET NULL、RESTRICT、NO ACTION。4.1 四种级联规则的语义和选择CONSTRAINT fk_orders_user FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE ON UPDATE CASCADE;CASCADE父表记录删除子表引用它的记录同步删除父表主键更新子表外键同步更新。SET NULL父表记录删除时子表外键列被置为NULL。前提是外键列允许NULL。RESTRICT如果子表还有引用记录禁止删除父表记录直接报错。这是MySQL的默认行为。NO ACTION和RESTRICT基本一致InnoDB里两者等价都是有引用就不让删。选择规则很简单业务上父没了子也没意义的强归属关系用CASCADE比如订单删除时订单明细一并删除父删了子要保留的弱关联用SET NULL比如删除商品时订单里的商品ID置为空吃不准时就用默认的RESTRICT先让业务自己处理。4.2 级联删除的锁开销与误删风险这里要讲一个真实教训。我之前接过一个项目为了方便给订单表和订单明细表之间加了ON DELETE CASCADE。某天运营在后台误删了一笔大额订单结果关联的几十条明细、甚至关联的支付流水记录全部被数据库自动清掉了。数据恢复花了一整夜。如果在应用层做删除前至少还有一次二次确认、有日志、有软删除的机会数据库级联删除是瞬间物理删除连后悔药都没有。另一方面级联删除会放大锁的范围。删除父表一行时InnoDB需要扫描子表索引来定位所有引用记录逐一加锁、删除。数据量大时这个操作会产生大量行锁和间隙锁事务持有锁的时间明显变长线上DML容易堆积。你在低并发测试环境感觉不到一到生产压测就暴露问题。4.3 什么时候才适合开级联根据我自己的实践适合用CASCADE的场景只有两类一是数据归属关系极强且生命周期完全一致比如草稿箱和草稿内容草稿删除内容必然删除二是内部管理系统的后台数据数据量小、并发低、可接受误操作风险。线上高流量的核心业务表不建议用。这是方便换安全和性能的典型交易多数情况下不划算。5. Java开发者的ORM落地JPA 与 MyBatis 里的主外键映射Java后端开发绕不开ORM框架。主键和外键在JPA和MyBatis里的映射方式是实际编码中接触最多的部分很多问题也出在这里。5.1 JPA的Id、GeneratedValue和关联注解先看用户实体Entity Table(name users) public class User { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; Column(nullable false, unique true) private String username; }再看订单实体Entity Table(name orders) public class Order { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; ManyToOne(fetch FetchType.LAZY) JoinColumn(name user_id, referencedColumnName id) private User user; }ManyToOne表示多个订单关联一个用户JoinColumn指定外键列叫user_id引用users表的id列。在JPA里关联关系就是通过这种方式表达的。GeneratedValue有四种策略最常用的是IDENTITY自增和SEQUENCE序列。MySQL不支持序列所以MySQL下一般用IDENTITY或AUTO。如果是分库分表场景通常不用数据库自增而用应用层生成ID这时可以用ASSIGNED配合自定义主键生成器。5.2 MyBatis的resultMap关联写法MyBatis更接近SQL本身。查询订单并带出用户信息可以这样写resultMap idOrderResultMap typecom.example.Order id propertyid columnid / result propertytotalAmount columntotal_amount / association propertyuser javaTypecom.example.User id propertyid columnuser_id / result propertyusername columnusername / /association /resultMap select idselectOrderWithUser resultMapOrderResultMap SELECT o.id, o.total_amount, u.id AS user_id, u.username FROM orders o LEFT JOIN users u ON o.user_id u.id WHERE o.id #{id} /selectid标签用来告诉MyBatis哪一列是唯一标识这在处理嵌套对象去重时很关键对应数据库主键的概念。而association对应多对一引用关系对应外键语义。5.3 实体关联关系不等于数据库外键约束这是Java开发者最容易混淆的一点。JPA里的ManyToOne和JoinColumn只是告诉ORM框架这两个实体在业务上有引用关系方便代码层面做关联查询、对象导航。它不一定会在数据库里创建物理外键约束。ddl-auto配置为create或update时Hibernate会根据实体关系自动生成外键约束但生产环境通常把ddl-auto设为none或validate数据库表结构由专门SQL脚本管理。也就是说生产数据库里可能根本没有外键约束但代码里的关联关系照样存在、照样能join查询。理解这个区别你就能明白为什么Java实体里配了外键关系但DBA说数据库里没有外键这种现象是正常的不是环境配置错了。6. 为什么大厂默认禁用物理外键应用层保证引用完整性的替代方案这是整个话题里最有工程价值的部分。很多Java开发者第一次听到禁用外键时会懵外键不是好东西吗为什么不让用6.1 阿里规范为什么这么规定《阿里巴巴Java开发手册》里明确写道不得使用外键与级联一切外键概念必须在应用层解决。这句话被无数团队奉为圭臬但很多人不理解背后的原因。核心原因有三个。第一分库分表之后外键失效。订单表和用户表如果被拆分到不同数据库实例数据库层面的外键约束根本无法跨实例工作。你做微服务拆分后订单服务和用户服务可能各自独占一个库外键约束在物理上就不成立了。第二外键约束会让数据库承担额外的检查开销。每次插入、更新子表的外键列数据库都要去父表索引里查一次每次删除、更新父表记录又要去子表索引里反查一次。这些操作在高并发下会放大锁竞争尤其大表之间的引用检查经常成为性能瓶颈。第三外键将业务耦合下沉到了数据库层。项目迭代快的时候经常出现先删用户、异步清理关联数据这种需求。物理外键强制要求即时一致性和异步解耦、消息队列这类架构天然冲突。6.2 禁用外键后引用完整性交给谁应用层方案并非什么都不做而是把引用完整性检查放到业务代码和流程里。常规做法包括写入时校验插入订单前先在业务代码中确认user_id对应的用户存在。这个校验在微服务里通常通过调用用户服务接口完成。事务保证涉及多张表的写入放到同一个本地事务中保证要么全部成功要么全部回滚。定期对账用定时任务扫描子表中的外键值找出孤儿数据并告警。虽然问题不是实时发现但能避免脏数据无限积累。软删除用deleted字段替代物理删除从源头避免父表删了子表不知道的尴尬。这套组合拳的代价是代码更繁琐但换来了架构弹性。数据一致性从数据库强约束变成应用层逻辑保证一旦破坏能快速定位到业务代码而不是面对数据库的一堆锁等待。6.3 什么时候可以保留外键也不是所有场景都禁用。我的判断标准是单库单应用、并发不高、团队规模小可以用外键它能省不少代码。强一致性要求的内部系统比如财务对账、后台权限模型外键是个好护栏。一旦开始做微服务拆分、分库分表或数据量过千万就要主动移除物理外键改为应用层管理。工程没有银弹外键也不是有罪只是它的适用场景在高并发分布式架构下变窄了。7. 主键选型决定应用上限自增、UUID、雪花ID怎么选主键选型是每个Java开发者最终都要面对的问题。这里我不打算罗列一堆理论直接讲三种方案在真实工程里的表现。7.1 自增主键性能好但有边界自增主键AUTO_INCREMENT是最常用的。优点非常实在B树叶子节点按顺序插入页分裂概率低写入性能好索引体积小BIGINT才8字节对Java来说就是一个Long序列化、比较都方便。但也有三个边界。一是安全风险自增ID直接暴露业务量竞品可以通过ID差值推断你的订单量所以很多产品会加一层混淆ID。二是分库分表痛苦多个库各自自增会撞ID需要改雪花ID或号段模式。三是数据迁移麻烦从老系统导数据时自增ID会和已有数据冲突需要先禁用自增、导入后再调整。7.2 UUID主键分布式友好但踩了聚簇索引的坑UUID作为主键最大的优点是客户端本地生成、全球唯一不需要数据库参与非常适合分布式写入。但用作InnoDB主键是一场灾难。UUID是随机字符串插入顺序完全随机InnoDB聚簇索引是按主键排序的随机插入会导致大量页分裂和页重组引发严重的随机IO。同时UUID占36个字符VARCHAR存储索引体积大辅助索引回表成本也高。在千万级数据量的表上随机字符串主键的写入性能可以比自增慢数倍。有一个折中方案使用有序UUID版本或把UUID转成BINARY(16)存储能缓解一部分问题但复杂性上去了。我的建议是能不用UUID做主键就不用。7.3 雪花ID兼顾分布式的趋势递增雪花ID是Java后端最流行的分布式主键方案。它是一个64位Long由时间戳、机器ID、序列号拼接而成。核心优势是趋势递增——前半段是时间戳所以整体上是递增的对聚簇索引比较友好同时又不依赖数据库各节点独立生成不冲突。实际使用中有几个坑要注意。一是时钟回拨问题机器NTP校时导致时钟回拨时可能会生成重复ID需要算法层面做处理。二是机器ID分配分布式环境下要确保每台实例的机器ID不冲突。三是前端精度问题这是Java项目最常见的一个雪花ID是个19位的Long而JavaScript的Number精度只有16位左右直接返回给前端会丢失精度。解决办法是用Jackson配置把Long序列化为String。当前主流做法是在Spring Boot里配置全局Jackson序列化器把Long和long统一转成String输出前端就不会丢精度了。7.4 Java侧的真实影响Long精度和序列化上面提到的精度问题值得再强调一下。后台返回订单ID为1391234567890123456前端JS拿到后变成1391234567890123400最后几位全变了。普通查询还问题不大一旦前端把这个ID传回来做更新就会出现更新了错误的记录这种极其隐蔽的bug。所以主键选型不只是数据库问题而是数据库、后端、前端三端联动的架构决策。自增Long、雪花ID Long都需要考虑序列化策略什么时候转String什么时候保留Long项目里应该有个统一约定。8. Java面试高频题主键外键的八股文和实战答法既然热搜词里出现了大量java面试八股文我就把主键外键最常见的面试题整理成一套答法。这些题本身不难但很多人挂在背了但没理解上。8.1 六个必问题目与回答思路第一个主键和唯一索引的区别答法主键不能为空且唯一唯一索引允许空值主键是聚簇索引唯一键是辅助索引一张表只能有一个主键但可以有多个唯一键。如果能补充InnoDB必须要有主键来组织聚簇索引这一层面试官会高看一眼。第二个为什么InnoDB表一定要有主键答法InnoDB是聚簇索引组织表数据行按主键顺序存储。主键的B树叶子节点就是完整数据行辅助索引叶子节点保存的是主键值。没有主键时InnoDB会找第一个非空唯一索引否则生成隐藏rowid。隐藏rowid不可见且不稳定所以建表时应该显式指定主键。第三个外键和JPA里ManyToOne的区别答法外键是数据库层的强约束保证引用完整性ManyToOne是ORM层的对象关系映射用于Java代码中方便地访问关联实体。前者是物理约束后者是逻辑关系。实际工程中经常只保留JPA关联而不用数据库外键。第四个为什么大厂禁用外键答法从分库分表、性能开销、微服务解耦三个角度回答具体参考第6章的内容。重点是让面试官知道你理解工程权衡而不是只会背规范。第五个一张表能有多个主键吗答法不能。一张表只能有一个主键但主键可以是复合的多个列联合构成。注意区分复合主键和多个主键。第六个删除父表记录时子表数据怎么办答法分情况。有外键约束时RESTRICT会阻止删除CASCADE会同步删除子表引用记录SET NULL会把子表外键置空。没有外键约束时就需要应用层自己处理孤儿数据比如软删除、定时清理或禁止删除有引用的父记录。8.2 主键与普通索引在实际执行计划里的差别还有一个进阶考点就是通过EXPLAIN看执行计划来理解主键索引和普通索引的差别。EXPLAIN SELECT * FROM users WHERE id 100; EXPLAIN SELECT * FROM users WHERE username zhangsan;第一条走主键索引PRIMARY由于是聚簇索引直接通过ID定位到数据行不需要回表。第二条如果username上有普通索引查询会根据索引找到主键值再通过主键回表取整行数据这就是回表的概念。如果查询的列都在索引里连回表都不需要就是覆盖索引。理解这层逻辑后你就能明白为什么主键越短越好——辅助索引里保存的是主键值主键越长所有二级索引的体积就越大占用内存和磁盘也越多。8.3 现场怎么演示外键创建慢和不用外键如果面试或分享时有现场演示的机会我会给一个对比实验。准备两张百万行级别的表一张带外键约束一张不带。分别执行大批量插入子表数据的操作带外键的表在子表产生新数据量最大时每秒吞吐量会明显下降因为每条子表数据都要去父表做存在性校验不带外键的表则没有这个步骤。这个实验很直观地解释了为什么高并发场景下外键会成为瓶颈。另一个演示是故意插入一条不存在的user_id带外键的表直接报Cannot add or update a child row错误不带外键的表则安静地插入成功。这正好证明外键的核心价值——引用完整性检查以及去掉外键后这个检查必须由应用层补上。说了这么多回到最开头那句话——主键和外键不难难的是在真实工程里拿捏好用它们的分寸。我的建议是主键一定要认真设计它是所有索引的根基外键在低并发、强一致、单体架构里放心用在高并发、分布式架构里果断让应用层接管。把这些想清楚不管是写代码还是面试你都比大多数人站得高一层。