MySQL五类约束全解析：从建表到防脏数据的核心防线

接手过几个维护期项目之后，你会慢慢发现一个规律：线上数据变脏，往往不是业务代码的bug，而是约束没设计好。重复的手机号能注册、子订单引用了不存在的父订单、员工表里age字段存了-3……这些问题的根子，大多在建模阶段就没想清楚约束该怎么加。约束这东西，建表的时候顺手写上几行，似乎没什么技术含量；可等到数据出问题那天，你才会意识到它才是数据库最便宜、最可靠的那道防线。

这篇内容没什么高深理论，就是把MySQL里五类约束——非空、唯一、主键、默认值、外键——掰开揉碎讲清楚。每个约束解决什么业务问题、建表时怎么写、线上怎么改、有哪些坑，全部覆盖。适合正在学数据库的初学者，也适合准备重构老表结构、想补上约束缺口的中级开发者。

1. 约束的本质：数据质量的声明式防线

先说一个容易忽略的事实：约束其实是数据库对业务规则的一种声明式表达。你在建表语句里写下一行约束，相当于告诉数据库引擎："凡是违反这条规则的数据，一律不许进来。" 这比在应用层写一百个if判断都可靠——因为不管数据是从哪个接口进来的、是哪个同事用脚本灌的、还是DBA手工刷的，只要走到这张表，就必须过约束这道闸。

约束的哲学在于"防"而不是"纠"。应用层校验是软性的，总有漏网之鱼，而且漏掉的时候你往往不知道；约束是硬性的，违反就报错，从源头保证你查出来的数据永远是你期望的形状。我见过太多团队对约束不上心，觉得"反正Java里都校验过了"，结果换了个临时脚本批量刷数据，直接把脏数据灌进生产库。这种教训一次就足够让人长记性。

具体来说，MySQL的约束体系分五条主线：

• NOT NULL（非空约束）：声明这一列必须有值。
• UNIQUE（唯一约束）：声明这一列（或列组合）不可重复。
• PRIMARY KEY（主键约束）：非空+唯一的合体，同时承担定位一行数据的职责。
• DEFAULT（默认值约束）：不填时给一个兜底值。
• FOREIGN KEY（外键约束）：声明这一列的值必须存在于另一张表的某列中。

这五类约束不是孤立存在的，它们经常组合出现。举个例子，用户表的手机号字段：

CREATE TABLE user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, phone VARCHAR(20) NOT NULL UNIQUE, nickname VARCHAR(50) NOT NULL, status TINYINT NOT NULL DEFAULT 1 );

这一条建表语句里，NOT NULL UNIQUE就是两个约束的组合：手机号既不能为空，也不能重复。DEFAULT 1保证了只要业务方不显示传status，进来就是正常状态。这就是约束组合拳的日常用法。

有些约束是"列级"约束，写在字段定义后面，比如NOT NULL和DEFAULT；有些是"表级"约束，写在字段列表之后，比如把多列组合成一个唯一键。搞清楚这个区别，等会儿写复杂约束的时候就不会晕。

提示：MySQL 8.0及以上版本，建表时若定义了约束但没起名字，系统会自动生成约束名。唯一约束默认叫字段名_2，外键默认叫表名_ibfk_1这种格式。线上环境建议显式命名，不然排错的时候光找约束名都够你喝一壶。

2. 五种约束逐个拆解：语法、适用场景与暗坑

这节我们从业务视角过一遍每种约束。直接给结论，再解释为什么这么用。

2.1 非空约束：比你想的更底层

非空约束在MySQL里不是一个独立的"约束对象"，它就是列定义的一部分。语法极简：

CREATE TABLE t_example ( name VARCHAR(50) NOT NULL, email VARCHAR(100) NULL );

NULL和NOT NULL的区别用一句话概括：NULL表示"不知道"或者"没有"，它参与任何计算都会把结果染成NULL。比如SELECT score + 10 FROM student，如果score是NULL，结果是NULL而不是10。这就是为什么很多字段必须声明NOT NULL——不是为了好看，是为了避免业务代码里到处躲NULL指针。

暗坑之一：空字符串和NULL是两回事。''是一个具体值，NULL是"没有值"。很多初学者以为WHERE name <> '张三'能把name为NULL的行也查出来，其实查不出来。NULL不参与任何比较运算，只能用IS NULL去查。所以如果你的业务里"没有填写"和"填了空串"语义不同，一定要想清楚是否加非空约束。

2.2 唯一约束：不是你想的"只是不重复"

唯一约束的逻辑声明是"这一列或这几列的组合，在整个表中不允许重复值"。有意思的是，MySQL实现唯一约束的方式，是自动创建一个唯一索引。你建一个唯一约束，等于同时建了一个索引。所以唯一约束不仅能防重复，还能加速查询。

CREATE TABLE user ( id INT PRIMARY KEY AUTO_INCREMENT, phone VARCHAR(20), UNIQUE KEY uk_phone (phone) );

这里我给了约束一个显式名字uk_phone，后面删除或修改约束时能直接找到它。

需要注意两个细节。

第一，唯一约束允许NULL重复。在MySQL里，NULL被视为"未知"，未知和未知不相等，所以你可以插很多条phone = NULL的记录而不触发唯一约束。如果你的业务要求"手机号要么不填，填了就绝不能重复"，或者"有手机号的行最多一条"，那光靠UNIQUE是不够的，还得配合其他逻辑。这是个经常被忽略的边界。

第二，删除唯一约束的语法不是DROP CONSTRAINT，而是DROP INDEX，因为它的本质是索引。到了MySQL 8.0虽然支持了DROP CONSTRAINT写法，但底层逻辑依然是索引操作。

多列组合唯一也很常见，典型场景是"同一个用户对同一个商品只能有一条评价记录"：

CREATE TABLE product_comment ( user_id INT NOT NULL, product_id INT NOT NULL, content TEXT, UNIQUE KEY uk_user_product (user_id, product_id) );

注意：多列唯一判断的是"组合值"重复，而不是单列。用户1评论商品A、用户1评论商品B，两条都能插入；用户1再评商品A，才触发冲突。

2.3 主键约束：非空唯一的合体，但更重要

主键和唯一约束最大的区别：主键是"行"的身份标识，它直接和存储引擎的物理组织方式挂钩。InnoDB的表就是一棵按主键排序的B+树，数据行直接挂在主键上。所以选主键是个策略性问题。

日常建表常见写法：

CREATE TABLE t_order ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, order_no VARCHAR(64) NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no) );

这里有个非常容易踩的坑：业务唯一键（order_no）和主键（id）是两套东西。我见过不少项目，设计表的人图省事，直接用订单号当主键。当时看没什么问题，等到业务发展、订单表数据量上千万后，订单号的随机字符串导致B+树索引频繁页分裂，插入性能肉眼可见地下降。主键尽量用自增整数或有序雪花ID，保证插入顺序近似递增。

另外，主键约束的索引名永远是PRIMARY，所以它和唯一约束在删除语法上不一样——主键本身不存在"删除约束名"这种操作，而是直接DROP PRIMARY KEY。

InnoDB还有一个隐藏规则：如果你建表时不主动定义主键，InnoDB会优先找一个非空的唯一索引当隐藏主键，都找不到就生成一个6字节的隐藏列。这会导致额外的存储开销和索引效率下降。所以，任何InnoDB表都应该显式定义主键，这不只是规范问题。

2.4 默认值约束：减少业务职责的兜底机制

默认值约束比较容易理解：插入时不传这一列，就自动填默认值。但用起来有三个细节值得展开。

第一，默认值是在INSERT语句没有显式指定该列时生效。如果你显式写明传NULL，那就是NULL，除非列定义了NOT NULL或DEFAULT有特殊处理逻辑。比如：

CREATE TABLE t_user ( status TINYINT NOT NULL DEFAULT 1 ); -- 不传status，取1 INSERT INTO t_user (status) VALUES (DEFAULT); -- 显式传2，取2 INSERT INTO t_user (status) VALUES (2);

第二，MySQL 8.0对DEFAULT表达式做了一次语法调整。8.0.13之前，函数的默认值必须加括号，比如DEFAULT (NOW())；8.0.13之后建议直接写DEFAULT CURRENT_TIMESTAMP，也支持表达式默认值了。如果你还停留在5.7的习惯，升级到8.0后要留意这个变化。

第三，默认值约束不改变列的可空性。一个列同时写DEFAULT 1但没写NOT NULL，那插入时传NULL照样能插进去。默认值只在你"完全不提这个字段"时生效。想让字段"不填就默认值、填了NULL就报错"，请组合使用NOT NULL DEFAULT 值。这两者的语义差异，业务人员讨论需求时经常混淆。

2.5 外键约束：跨表完整性，但很多人不敢用

外键约束是把数据完整性从单表提升到跨表：从表的外键列值，要么是NULL，要么必须存在于主表被引用列中。经典场景是订单明细表引用订单主表：

CREATE TABLE t_order ( id BIGINT PRIMARY KEY, order_no VARCHAR(64) NOT NULL ); CREATE TABLE t_order_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, product_name VARCHAR(100) NOT NULL, CONSTRAINT fk_item_order FOREIGN KEY (order_id) REFERENCES t_order(id) ON DELETE CASCADE ON UPDATE RESTRICT );

这里有几个必须搞清楚的底层限制：

• 被引用的列必须有索引。通常引用主键就没问题；如果引用非主键列，那张表该列必须有唯一约束或普通索引，否则MySQL会报错——外键列上如果没有索引，MySQL会自动创建一个，但在从表上创建是要付出DDL代价的。
• 外键只支持InnoDB。MyISAM虽然允许写外键语句，但引擎会直接忽略它。这是个极其隐蔽的坑：你满怀信心地写了FOREIGN KEY，以为数据完整性有保障了，结果插了脏数据也没报错，因为MyISAM根本不理会你。
• 类型必须严格匹配。主表BIGINT，从表INT，即使数值范围能放得下，MySQL也不允许建立外键。字符集的排序规则也得一致。

那为什么很多团队在生产环境里"禁用外键"？主要原因是性能和高并发下的锁问题。外键约束每次写入都要去检查主表，多了一次查询，而且在某些场景下会扩大锁范围，影响并发。这不是外键本身错，而是用错了地方。我的建议是：核心交易链路、并发量高的表尽量不用外键，靠应用层保证；后台管理系统、配置表、数据一致性要求极强但写入量低的场景，外键值得用。严格分级看待，而不是一刀切。

3. 约束设计的实战思路：从建表开始就减少未来的坑

约束不是写完就完事的，它的设计直接关系到你未来两年维护这个表的幸福感。这节讲讲我在实际项目中是怎么取舍的。

3.1 列属性设计的顺序：先定类型，再定约束

很多新手建表先纠结"这列该不该有默认值"，其实顺序反了。正确顺序是：

1. 先确定这列存什么类型的数据，选对类型（整数、字符串、日期、布尔）。
2. 再问语义：这列能不能为空？如果业务上"没有"和"填了空串"含义不同，就按需加NOT NULL。
3. 再问规则：这列允不允许重复？需要的话加UNIQUE。
4. 最后问兜底：如果不填，给什么默认值？

举个例子，一个后台员工表的last_login_time字段。业务上"从未登录"是一个合法的中间状态，所以这一列允许为NULL比较合理；但如果你用DATETIME DEFAULT CURRENT_TIMESTAMP，那就意味着"创建时默认等于创建时间"，这不等于"从未登录"，语义直接冲突了。

所以我倾向于这样设计：

last_login_time DATETIME NULL DEFAULT NULL

这样查询时用IS NULL来判断"从未登录"逻辑，既不会误伤，也不会产生歧义。

3.2 组合约束的几个经典案例

案例A：逻辑删除与唯一约束的冲突

业务上最常见的需求是"同一用户不能有两个未删除的手机号记录"，但你做的是逻辑删除（is_deleted），物理数据还在表里。如果直接在phone上建唯一约束，删掉一条再插同号会被卡住。解决方案通常有两种：

• 把删除标记并入唯一键：UNIQUE KEY uk_phone_deleted (phone, is_deleted)。但问题是同一个手机号被删两次，(phone, 1)又插不进去了。
• 更通用的方案是引入"删除批次号"：deleted_batch VARCHAR(32) NOT NULL DEFAULT ''，然后唯一键设为(phone, deleted_batch)。删除时给该行生成一个UUID批次号，物理上没有重复的(phone, uuid)了。这种设计常见于需要大量逻辑删除场景的业务表。

案例B：联合唯一是分页数据的天然保证

比如一个角色权限关联表(role_id, permission_id)，联合唯一既防重复，又能充当查询索引。一张中间表如果连联合唯一都没有，迟早会插出大量重复授权记录，接口返回来满屏相同数据，排查起来相当痛苦。

案例C：默认值与业务状态机配合

状态字段用TINYINT NOT NULL DEFAULT 0，配合一张枚举表说明每个数字的含义。不要在状态列上直接设NULL，否则业务里"空状态"和"无状态"混在一起后，统计口径会崩。

3.3 到底要不要所有字段都加NOT NULL

网上有种说法是"禁止任何字段为NULL"，这个观点过于绝对。有些字段确实该允许NULL，比如"备注""扩展信息""最后登录时间"。这些字段的NULL值可以被当成一种携带信息的状态。真正的区别在于：NULL是否有业务语义。有语义，就保留NULL；没语义，就一律NOT NULL + DEFAULT。

我见过一个比较稳妥的分法：

• 所有参与运算、统计、比较的数值字段：一律NOT NULL DEFAULT 0
• 所有状态位、标志位：一律NOT NULL DEFAULT 0或NOT NULL DEFAULT 1
• 所有时间字段：按需选择，但"创建时间"通常NOT NULL DEFAULT CURRENT_TIMESTAMP
• 自由文本、备注、扩展字段：允许NULL，但查询时心里要清楚NULL的语义

4. 约束的后期管理：改约束比建约束容易踩坑

建表时想清楚约束是最好的，但现实往往是老表已经跑了好几年，数据里存了一堆脏值，这时候想补约束，麻烦就来了。这节我讲几个改约束的场景和操作细节。

4.1 给已有表添加约束

给已有列添加非空约束时，MySQL要求该列现有数据不能有NULL。所以老表加NOT NULL前，通常先做一次数据清洗：

-- 步骤1：把NULL值替换为兜底值 UPDATE t_user SET nickname = '未填写' WHERE nickname IS NULL; -- 步骤2：修改列属性 ALTER TABLE t_user MODIFY COLUMN nickname VARCHAR(50) NOT NULL DEFAULT '未填写';

同样的道理，给已有列加唯一约束前，得先确认没有重复数据：

-- 查询有重复的组 SELECT phone, COUNT(*) FROM t_user GROUP BY phone HAVING COUNT(*) > 1; -- 去重完成后，再添加唯一约束 ALTER TABLE t_user ADD UNIQUE KEY uk_phone (phone);

这一步如果数据量巨大，比如千万级，必须先评估耗时。ALTER TABLE在MySQL 5.7及以下版本是锁表的，8.0虽然引入了ALGORITHM=INPLACE优化，但一些场景依然会锁。大表加约束，务必在低峰期执行，或者借助在线变更工具。

4.2 删除与修改约束

删除主键：

ALTER TABLE t_user DROP PRIMARY KEY;

删除唯一约束（本质删索引）：

ALTER TABLE t_user DROP INDEX uk_phone;

删除外键约束（注意要用约束名，不是列名）：

ALTER TABLE t_order_item DROP FOREIGN KEY fk_item_order;

修改约束通常没有"一条语句直接改"的路径，一般是先删再加。比如你想把某个唯一约束从单列换成多列组合，就要先删旧约束，再ADD新约束。这中间有个空窗期，操作要在事务或低峰期处理，防止期间插入重复数据。

4.3 SQL_MODE对约束的隐性影响

约束的行为受sql_mode影响，这点容易被忽略。

在宽松模式下（比如sql_mode不含STRICT_TRANS_TABLES），向NOT NULL列插入NULL，MySQL不报错，而是把列改成隐式默认值，只产生一条warning。很多研发在本地开发环境没开严格模式，测试怎么插都"成功"，上线后在生产环境被报错搞得一头雾水。开发、测试、生产三个环境的sql_mode保持一致，是约束正常工作的前提。

MySQL 8.0默认sql_mode是带严格模式的，5.7也默认开启。但某些云数据库默认配置可能被调过。建议执行下面语句确认一下：

SELECT @@sql_mode;

比较理想的配置至少包含STRICT_TRANS_TABLES和NO_ENGINE_SUBSTITUTION，前者保证约束不被悄悄绕过，后者防止建表时引擎被静默替换。

4.4 线上改约束的经典事故场景

我参与过一次事故排查，印象极深：某后台系统的用户表，mobile列历史上有大量NULL和重复值。团队给mobile加了唯一约束之后，当天晚上发现有一个定时任务开始报错——因为这个任务执行时如果手机号为空，会往表里插入一条mobile = NULL的记录。字段本身没有NOT NULL，而唯一约束又允许NULL重复，所以当时插入没失败；问题出在另一个地方：这个任务还会把空手机号更新成同一个兜底字符串''，空串是具体值，唯一约束拦住了第二次更新。结果就是任务永远卡在第一次更新之后，形成了一个极其隐蔽的循环失败。

后来怎么解的？把mobile的语义彻底分清：要么为空（NULL），要么为用户真实手机号。加了NOT NULL DEFAULT ''后，再配合正则校验，才把这块彻底稳住。这件事让我养成了一个习惯：加约束前把"现有数据里有哪些非法值"完整列一遍，再决定兜底策略。别让约束成为定时炸弹。

5. 约束与索引的协作关系：一张表的设计权衡

约束和索引在MySQL里是纠缠在一起的。唯一约束创建唯一索引，主键创建主键索引，外键创建普通索引。理解这层关系，你才能在设计表时做出合理的权衡。

这张表意味着，你每加一个唯一约束，就同时获得了一个查询加速能力。比如用户表的phone列加了唯一约束，那么按手机号登录时用的索引覆盖就有了。同理，外键列自动生成的索引也能加快从表按主表ID反查的速度。

但反过来，索引不是免费午餐。每个索引都会增加写入的开销，因为插入、更新、删除时都要同步维护索引树。所以约束加得太多太滥，也会让写入变慢。设计原则是：该有的约束必须有，不必要的索引一个也别留。比如一张只有几十行数据的配置表，加不加索引无所谓；一张日增百万的流水表，每个多余的索引都是实打实的写入损耗。

还有个关联点：唯一约束和普通索引在去重场景下的选择。如果你想"防重复"，必须用唯一约束；如果你只想"加速查找"，用普通索引就够了。后者允许重复值，但写入开销更小。搞清楚业务自己要的是什么，不要为了"顺手"就乱加。

在分库分表的大数据架构下，唯一约束的效果会打折——唯一性只能在单个分片内保证，跨分片就无能为力了。这种场景下唯一ID通常由全局发号器生成，数据库约束已经退居二线。如果是单库单表的项目，约束依然是性价比最高的防线，先把数据库约束吃透，再谈中间件层的高级方案。

6. 一张表描述全部：约束设计的完整示例

最后用一个相对完整的示例把上面所有内容串起来。假设我们设计一张简单的订单表，业务规则是：订单号必填且唯一、下单用户必填、订单金额默认0、状态默认待支付、备注可空、关联的用户必须存在。

CREATE TABLE t_order ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键', order_no VARCHAR(32) NOT NULL COMMENT '订单号', user_id BIGINT UNSIGNED NOT NULL COMMENT '下单用户ID', amount DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT '订单金额', status TINYINT NOT NULL DEFAULT 0 COMMENT '0待支付 1已支付 2已取消', remark VARCHAR(255) NULL COMMENT '备注', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id), CONSTRAINT fk_order_user FOREIGN KEY (user_id) REFERENCES t_user(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这个设计的逻辑是这样的：

• id自增主键保证行物理顺序插入有序，避免随机主键带来的页分裂。
• order_no是业务单号，单独做唯一约束，天然防重复下单。
• user_id建外键关联用户表，保证订单不会落到不存在的用户头上。如果并发量极高，这一条可以拆掉放到应用层校验，但一般的后台业务外键完全扛得住。
• amount用DECIMAL(10,2)而不是FLOAT，避免浮点误差；默认0保证统计时不出现NULL陷阱。
• status用TINYINT NOT NULL DEFAULT 0，并注释清楚状态含义。
• created_at和updated_at都是数据库层维护，应用层不用管。

这里面其实还隐含了一个设计细节：KEY idx_user_id (user_id)。虽然外键会自动建索引，但如果你决定不用外键，这个索引得手动建，否则按用户查订单的SQL会全表扫。约束可以拆掉，索引不要忘记留。

7. 实际维护中的几个个人体会

约束这东西，建表时多花十分钟琢磨，能替你在未来省下几个通宵。说几个我自己的坚持：

第一，任何表都必须有主键，尤其是InnoDB表。就算业务上找不到天然的唯一键，建一个自增id，成本最低、收益最高。没有主键的InnoDB表在复制、备份、数据修正时都会出各种幺蛾子。

第二，唯一约束的语义要落到字段组合而不是直觉。好好理清"哪些列组合起来才是业务上的唯一"，比到处乱加约束重要得多。一个约束加错，后面业务方会天天来提工单。

第三，改约束前先备份、先查重复、先看执行计划。一套组合拳下来，线上事故率会低很多。尤其是大表加唯一约束，一定要先在从库或测试环境完整跑一遍，算好时间窗口再动生产。

第四，把约束的删除脚本留在项目的数据库变更记录里。哪天约束定义有变化，你能清楚地从历史记录里看到这个字段以前是什么约束、为什么改。这比靠记忆靠谱得多。

最后分享一个小技巧：用SHOW CREATE TABLE查看别人建的表时，先扫一遍约束定义再扫字段定义。约束规划往往比字段类型更能反映设计者对业务的思考深度。你读懂了约束，就读懂了半张表。