刚接手维护线上库那阵子，我干过一件挺丢人的事：往用户表里导数据，导完才发现同名账号居然存了三十多条，建表时连唯一约束都没加。数据一脏，后面写什么业务逻辑都是拿脏数据在垃圾上盖楼。后来每次做表结构评审，我第一眼看的不是索引，反而是约束那一小块。今天就把MySQL表的约束彻底捋一遍，从非空、默认、主键、唯一、自增到外键和CHECK，讲清楚每个约束解决什么问题、怎么写、有什么坑，最后用一个学生课程成绩系统的表设计走通全流程。这篇内容对刚入门的同学是一次完整的补课，对有几年经验但一直凭感觉建表的人，也能帮你把零散的经验串成体系。
1. 约束是什么，为什么缺了它数据库会变成垃圾场
1.1 一张没有约束的表会失控
先聊一个最直接的问题：数据库里的约束到底在管什么事？
约束的本质，是数据库替应用层守规矩。程序写得不严谨、接口传参没校验、开发临时跑一段脚本，这些情况每天都在发生。如果没有约束，任何一条烂数据都能顺利进表：性别字段存“男/女/妖怪”，成绩负三百分，学号重复，学生表里引用的班级编号在班级表里根本不存在。等这些数据进去以后再想清理，SQL要写一大坨，线上还要停机，代价翻了几十倍。
我见过最典型的反面教材是一张订单表，没做主键，同一个订单号在库里出现了七次。后来对账系统一跑，金额差了几百万，排查了两天，最后发现是插入接口在并发重试时把同一笔订单写了多遍。如果有主键或唯一约束，第二次插入直接报Duplicate entry，根本轮不到脏数据落库。约束就是数据库在入口处设的那道闸门，宁可让程序报错停下来，也不能让错误数据越过去。
1.2 六大约束全景图
MySQL里的约束通常分成六类，虽然严格来说DEFAULT算字段属性，但工程上习惯和约束放在一起管理。先整体过一遍：
| 约束类型 | 作用 | 建表时写法示例 | 典型落地场景 |
|---|---|---|---|
| NOT NULL | 字段不允许为NULL | name VARCHAR(50) NOT NULL | 姓名、订单号等必填信息 |
| DEFAULT | 字段不传值时给默认值 | status TINYINT DEFAULT 0 | 订单状态、开关标记 |
| PRIMARY KEY | 唯一标识一条记录，隐含非空+唯一 | PRIMARY KEY(id) | 每张表的主键 |
| UNIQUE | 字段值或组合值不允许重复 | UNIQUE KEY uk_email(email) | 邮箱、身份证号、业务单号 |
| FOREIGN KEY | 字段值必须来自父表对应列 | FOREIGN KEY(stu_id) REFERENCES student(stu_id) | 子表引用父表主键 |
| CHECK | 字段值必须满足指定表达式 | CHECK (score >= 0 AND score <= 100) | 取值范围校验 |
这里面只有PRIMARY KEY和FOREIGN KEY属于表级约束里比较重的类型，其余都可以做列级约束。实际建表时，很多同学只记得主键和唯一，把NOT NULL和DEFAULT当成可有可无的选项，结果就是业务代码要写一堆if判空。我个人的经验是：建表的第一遍就把非空、默认、唯一全部定清楚，后面省下来的都是全组开发反复判断空值的加班时间。
1.3 约束命名的工程价值
约束在MySQL里本质上是一个数据库对象，外键、CHECK、唯一键都可以起名字。如果不起名字，MySQL会按默认规则自动命名，比如外键叫表名_ibfk_1，唯一键叫字段名，一旦后续要做删除或变更，你得先去information_schema查它到底叫什么。
我建议所有约束都显式命名，命名规则统一成类型_表名_字段名：
- 主键：
PRIMARY KEY (id)，不需要额外名字； - 唯一键：
UNIQUE KEY uk_user_email (email)； - 外键：
CONSTRAINT fk_score_student FOREIGN KEY (stu_id) REFERENCES student(stu_id)； - 检查约束：
CONSTRAINT chk_score_range CHECK (...)。
好处很直接：线上出问题时要执行ALTER TABLE ... DROP FOREIGN KEY fk_score_student，看一眼名字就知道要删哪个键，不用去翻元数据。这在后面第5章的排障环节会体现得更明显。
2. 逐个拆解：非空、默认、主键、唯一、自增和CHECK
2.1 NOT NULL与NULL的真实语义
NULL和空字符串是两个完全不同的东西，这条一定要刻在脑子里。
NULL代表“未知、不存在、还没赋值”，空字符串''代表“我知道这是个空内容”。统计函数的行为完全不同：COUNT(score)不会统计NULL值，但会统计空串；AVG(score)遇到NULL会跳过，遇到空串会按0计算。如果字段没加NOT NULL，线上数据里一旦混入NULL，报表统计出来的数字就会莫名其妙。
设计字段时的判断标准很简单：这个字段在业务上是否必须存在。必须存在就加NOT NULL，同时最好配合DEFAULT；确实有可能为空，比如“备注”“缺考成绩”，才允许NULL。这里有一个实践细节：允许NULL的字段建立索引时，NULL值在索引中也是占位置的，而且唯一索引里多个NULL是允许共存的，因为MySQL认为两个未知值并不相等。这样一来，如果业务上要求“邮箱一旦填写就不能重复，没填的就当重复”，那唯一约束对NULL就完全不起作用。想要真正做到“NULL也视作重复值”，可以额外加一个生成列：
ALTER TABLE student ADD COLUMN email_dedup VARCHAR(100) GENERATED ALWAYS AS (COALESCE(email, '')) STORED, ADD UNIQUE KEY uk_email_dedup (email_dedup);这样没填邮箱的多条记录在email_dedup列上都是空串，唯一索引会直接拦截住。
2.2 DEFAULT默认值里容易被忽视的细节
DEFAULT解决的场景非常朴素：插入时没传某个字段，数据库帮你填一个值。最常用的就是状态字段，比如订单状态默认0表示待支付，这就是热词里“mysql设置默认值为0”对应的场景：
CREATE TABLE `order` ( id BIGINT PRIMARY KEY AUTO_INCREMENT, status TINYINT NOT NULL DEFAULT 0 COMMENT '0-待支付，1-已支付，2-已取消' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;有几个细节值得注意。
第一，DEFAULT和NULL不是一回事。加了DEFAULT 0但没加NOT NULL的字段，插入时显式传入NULL仍然会存成NULL，因为DEFAULT只在完全不传这个字段时生效。所以想要“既能默认又能防NULL”，必须写NOT NULL DEFAULT 0。
第二，MySQL 8.0的DEFAULT支持表达式。以前默认值只能写常量，8.0之后可以写DEFAULT (UUID())、DEFAULT (CURRENT_TIMESTAMP + INTERVAL 1 DAY)这种带括号的表达式。如果还在用5.7，表达式会直接报语法错误。
第三，DATETIME类型想跟MySQL当前的写入时间走，可以直接写DEFAULT CURRENT_TIMESTAMP，但如果你用的版本较老，TIMESTAMP类型有自动更新机制，DATETIME没有，建表时容易踩时间默认值为0的坑。排查时看到0000-00-00 00:00:00这种货色，基本就是时间字段的DEFAULT没配好或者是用了MySQL的explicit_defaults_for_timestamp变量导致行为变化。
2.3 PRIMARY KEY与UNIQUE的选型对比
PRIMARY KEY是整个表的身份标识，UNIQUE是业务上的唯一性约束。一个表只能有一个主键，但可以有多个唯一键。主键默认非空加唯一，UNIQUE只保证唯一，不保证非空。
主键选型上，最常见的两个方向是自增主键和业务主键。
- 自增主键：
id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY，插入不传id，数据库自己分配。优点是写法简单、性能好，做表关联时B+树插入基本是顺序追加；缺点是分布式场景下自增会冲突，需要改雪花ID这类方案。 - 业务主键：直接用学号、身份证号、订单号这类业务上本来就唯一的字段做主键。优点是省掉一列冗余，查询时不需要回表找业务字段；缺点是业务主键一旦改了，改动成本极高，而且字符型主键在InnoDB聚簇索引里会让插入变得随机，性能可能不如自增。
我个人倾向：能用自增就用自增，除非业务主键本身很稳定且短。学号这种看起来稳定，但学位制度调整、学籍系统升级时改学号的情况并不罕见，一旦拿它做主键，关联表和主键本身都要跟着变动，非常痛苦。
还有一种情况是复合主键，由多个字段共同构成唯一标识。成绩表里用(stu_id, course_id, exam_batch)做主键，意思是一个学生在一门课的同一场考试里只能有一条成绩记录，这个组合在业务上天然唯一，用它做主键既节省一列自增id，又能直接防止重复成绩写入。复合主键也有代价：所有引用它的外键都要带全部列，关联查询的条件也会变长，所以只在业务约束强烈时使用。
再对比一下UNIQUE键。唯一约束的落地场景包括邮箱、手机号、身份证号、业务单号等。建表时一旦加了UNIQUE，MySQL会自动在该字段上建一个唯一索引，查询时直接可走索引。这里有一个常见误解：有些人以为加了UNIQUE就能“防NULL”，前面已经说过，多个NULL在唯一索引下并不冲突。要看业务语义，必要时用生成列配合。
2.4 AUTO_INCREMENT自增主键的使用细节
自增主键是MySQL里最常见的默认配置，但细节之多少人踩坑。
第一个坑：删了数据不自增回收。一张表的自增计数器是只增不减的，即使把表里最大的几条记录删掉，AUTO_INCREMENT也不会自动回退。想要重置可以用ALTER TABLE t AUTO_INCREMENT = 1，但前提是当前表里没有更大的id，否则会报错或者重置失败。
第二个坑：事务回滚后id会跳号。InnoDB引擎下自增计数器的分配和事务提交不是绑定的。插入一行，事务回滚，但分配的id已经消耗了，下一次插入会跳过这个数字。很多刚入门的人看到id中间有空洞，以为数据被删了或者出bug了，其实这是自增的正常行为，不必恐慌。
第三个坑：批量插入时自增锁模式影响并发和跳号。MySQL的innodb_autoinc_lock_mode参数控制自增锁的分配方式：0表示传统模式，每条insert都锁表；1表示连续模式，批量insert仍然锁，但simple insert用互斥量即可；2表示交叉模式，多线程批量插入交叠分配，一定范围内可能出现不连续。从并发角度看，8.0默认的2模式性能更好，代价是自增序列可能跨事务乱序，所以如果要追求“严格连续”，那是做不到的，也不该用数据库解决这种需求。
第四个坑：插入特殊id后自增失步。手工往表里插入一个大id（比如100000），再让数据库自己自增，计数器会跟着变到100001。这种操作在导数据时很常见，导完老系统数据之后，如果某个历史id大于当前计数器，新插入的id就可能撞上老记录，唯一约束直接挡下来。解决办法是导完数据后手动把AUTO_INCREMENT调整为max(id)+1。
2.5 CHECK约束的版本差异和写法
CHECK约束在MySQL里有一段很尴尬的历史。5.7及更早版本里，CHECK约束会被解析但直接忽略，也就是说你写了CHECK (score >= 0 AND score <= 100)，它不会报错，但也不会拦任何数据。这就是很多人说“MySQL的CHECK没用”的原因。
从MySQL 8.0.16开始，CHECK约束才真正被强制执行。所以如果你的项目还在用5.7，就别指望用CHECK做业务校验了，老老实实把校验逻辑写到应用层，或者考虑升级。等到8.0.16以上，才可以放心使用CHECK来限制字段的取值范围。
语法上要注意，无论列级还是表级，CHECK后面的表达式必须是确定性的，也就是不能包含存储函数、用户变量、子查询这些。常见的写法：
-- 列级 gender CHAR(1) NOT NULL DEFAULT 'U' CHECK (gender IN ('M', 'F', 'U')) -- 表级，适合引用多个字段 CONSTRAINT chk_score_value CHECK (score_value >= 0 AND score_value <= 100)这里有个容易忽略的细节：CHECK约束对已经存在的脏数据不负责。给一张已经灌满数据的表新增CHECK约束时，如果现有数据不满足条件，MySQL 8.0会直接不允许加，需要先把脏数据洗掉再加。反过来，在5.7时代建的CHECK会被静默忽略，历史表里早就有越界数据了，升级到8.0后如果执行开启约束校验的DDL，才会真正开始拦数据。
3. FOREIGN KEY外键：引用完整性是最容易被低估的一环
3.1 外键解决什么问题
外键解决的是引用完整性问题。成绩表里的stu_id必须真实存在于学生表，成绩表里的course_id必须真实存在于课程表。没有外键时，数据自己不会管这件事，应用层漏掉一环，脏引用就进去了。
有外键时，子表插入不存在的父表引用值时，MySQL会直接报错：
INSERT INTO score (stu_id, course_id, exam_batch, score_value) VALUES ('NOEXIST001', 1, '2024-01', 90); -- 报错：Cannot add or update a child row: a foreign key constraint fails这种报错看着烦，但它保护的是数据质量的底线。我见过不少项目删了外键，理由是“影响性能”，结果应用层又没跟上，最后子表里全是孤儿数据，查询全得靠LEFT JOIN再过滤，逻辑越来越绕。
3.2 建立外键的硬性条件
MySQL里建外键不是随便写个FOREIGN KEY就行的，有一连串硬性条件，不满足就报Cannot add foreign key constraint。把这些条件逐条背下来能省很多排查时间：
- 父表的关联列必须是索引，而且通常是主键或唯一键；
- 子表和父表的字段数据类型必须完全一致，不仅类型一致，连
UNSIGNED这种属性都要一致； - 两张表的字符集和排序规则一致，否则字符串比较时索引对不上；
- 两张表的存储引擎都必须是InnoDB（或支持外键的引擎），MyISAM不支持外键；
- 子表的外键列上会自动创建索引，这也是InnoDB的默认行为，相当于省了一步手动建索引。
排查外键报错时，按这个顺序检查，基本一分钟内能定位到原因。尤其字符集不一致这个问题，经常在建表时被忽略，报错信息又不会直接提示是字符集，很多人在那盯着数据类型看半天找不到原因。
3.3 四个级联策略怎么选
外键本质上是定义了父表和子表的联动规则。父表数据被更新或被删除时，子表该怎么办？MySQL支持四种规则，关键是删除操作的行为：
| 策略 | 删除父表记录时子表行为 | 使用场景 |
|---|---|---|
| RESTRICT | 直接拒绝删除，报外键错误 | 默认策略，防止误删被引用的数据 |
| NO ACTION | InnoDB下和RESTRICT等价 | 语义上表示“什么都不做”，实际也会报错 |
| CASCADE | 子表引用该父记录的行一起删除 | 父子生命周期一致，比如删学生连带删成绩 |
| SET NULL | 子表外键列被置为NULL | 子表该字段允许NULL，父表删除后保留子表记录 |
SET DEFAULT在InnoDB里实际上不被支持，设置了也会被忽略或报错，这一点和部分其他数据库不同。
选级联策略时我很强调业务语义。拿学生课程成绩系统的三张表来说：删除一个学生，他的成绩记录没有保留价值，所以ON DELETE CASCADE合理；删除一门课程，已经考过的成绩在业务上需要追溯，就算课程被删了成绩单里还得有记录，所以ON DELETE RESTRICT更合适，不给删。如果把两个都设成CASCADE，删课程时成绩单跟着蒸发，审计时记录就没了，后果很严重。
3.4 为什么很多高并发团队刻意不用外键
外键不是银弹，这是必须坦诚说的。
外键在写入时有一个隐藏开销：子表插入一行或更新外键列时，InnoDB需要对父表对应行加共享锁，确认父行存在，整个链路多了锁的获取和释放。在高并发写入场景下，这个锁会成为热点，两个事务互相持有对方需要的锁时还可能触发死锁。
再加上分库分表后外键基本没法跨库使用，联合索引、分布式ID这些改造都和外键冲突。所以很多中大型互联网项目会选择不在数据库层建外键，而是把引用完整性放到应用层去保证，比如写一个校验服务统一判断，或者在写入接口里显式查询父表记录是否存在。
这种取舍和约束设计的大原则不矛盾。约束是用来保护数据质量的，外键是其中一种保护手段。如果你能通过接口规范、上线评审、代码测试把引用完整性问题挡在入口之外，不用外键完全可行；但如果你是在一个人手不足、快速迭代、CI又经常漏测的小团队里，我反而建议保留外键。外键的校验是免费的，而应用层的校验是每次都要写代码的，谁都会忘。
4. 一个完整案例：学生课程成绩系统的三张表
4.1 需求与表结构规划
前面讲的都比较零散，现在把它们串成一个完整案例。假设现在要为学生课程成绩系统设计实体表，业务需求如下：
- 学生有学号、姓名、性别、邮箱、出生日期；
- 课程有课程号、课程名、学分；
- 一个学生可以选多门课，一门课可以被多个学生选；
- 学生选课后会产生成绩，成绩和具体哪场考试绑定；
- 需要防止同一学生在同一场考试中对同一门课程出现多条成绩记录。
从需求出发，最自然的拆分就是三张表：学生表、课程表、成绩表。学生和课程之间是多对多关系，中间就是成绩表。这正好契合“学生课程成绩信息实体表设计mysql”这个热词背后的核心场景。
4.2 学生表实现
学生表以学号为业务主键，这个决定要慎重，前面说过业务主键的优缺点。学号在每个学校内唯一且稳定，用它做主键能省掉一个自增id字段，这里为了演示约束的多样性，保留业务主键写法：
CREATE TABLE student ( stu_id CHAR(10) NOT NULL COMMENT '学号', name VARCHAR(50) NOT NULL COMMENT '姓名', gender CHAR(1) NOT NULL DEFAULT 'U' COMMENT 'M-男 F-女 U-未知', email VARCHAR(100) COMMENT '邮箱', birth_date DATE COMMENT '出生日期', PRIMARY KEY (stu_id), UNIQUE KEY uk_student_email (email), CONSTRAINT chk_student_gender CHECK (gender IN ('M', 'F', 'U')) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生表';逐个看约束选择：
stu_id设为主键，学号唯一、非空，不需要额外加唯一键；name加NOT NULL，入学一定有名；gender用单字符存，加DEFAULT 'U'，再加CHECK限制只能三个值。这是CHECK约束的标准应用场景；email允许NULL，但业务上邮箱不能重复，所以加UNIQUE。前面提到过，这个唯一约束管不住多个NULL的重复，这里因为业务上“没填邮箱就不算重复”，语义刚好吻合。
4.3 课程表实现
课程表用自增主键，课程号这种编号和学号不一样，它内部生成，没有外部变更约束，用自增最省心：
CREATE TABLE course ( course_id INT NOT NULL AUTO_INCREMENT COMMENT '课程号', course_name VARCHAR(100) NOT NULL COMMENT '课程名', credit TINYINT UNSIGNED NOT NULL DEFAULT 2 COMMENT '学分，默认2学分', PRIMARY KEY (course_id), CONSTRAINT chk_course_credit CHECK (credit BETWEEN 1 AND 10) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='课程表';credit TINYINT UNSIGNED的类型选择是想说明一个点：字段类型本身就是一道约束。学分不可能为负，直接用无符号整数在类型层面就把负值堵死了，比写一堆CHECK更彻底。类型选得合适，很多业务校验代码根本不需要写。
4.4 成绩表：复合主键与外键的配合
成绩表是这三张表里约束最密集的表，也是体现表设计功力的地方：
CREATE TABLE score ( stu_id CHAR(10) NOT NULL COMMENT '学号', course_id INT NOT NULL COMMENT '课程号', exam_batch VARCHAR(20) NOT NULL DEFAULT '2024-01' COMMENT '考试批次', score_value DECIMAL(5,1) COMMENT '成绩，缺考则为NULL', PRIMARY KEY (stu_id, course_id, exam_batch), CONSTRAINT fk_score_student FOREIGN KEY (stu_id) REFERENCES student(stu_id) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT fk_score_course FOREIGN KEY (course_id) REFERENCES course(course_id) ON DELETE RESTRICT ON UPDATE CASCADE, CONSTRAINT chk_score_value CHECK (score_value IS NULL OR (score_value BETWEEN 0 AND 100)) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='成绩表';这张表把前面所有约束类型都融合了：
PRIMARY KEY (stu_id, course_id, exam_batch)让“同一学生同一课程同一场考试只能有一条成绩”，这是逻辑上天然的唯一性；- 两个外键分别指向学生表和课程表，保证成绩记录上的学生和课程都真实存在；
score_value允许NULL，代表缺考或未出成绩，又用CHECK限制非NULL时必须在0到100之间。这里的CHECK写法要特别注意，因为score_value IS NULL时条件为真，所以允许NULL通过约束，不会误杀缺考记录；- 外键级联策略遵循前面分析的逻辑：删学生时成绩一并删除，删课程时禁止直接删除，必须得先处理成绩数据；
ON UPDATE CASCADE保证学号或课程号一旦变更，成绩表里的引用会自动更新，免去手工同步。
4.5 用几条不合理的SQL验证约束
表建完了，真正测约束是往里插错误数据，看数据库怎么反应。这是我最推荐的验证方式，比看任何文档都直观。
插一条成绩，学生不存在：报外键错误，stu_id被挡下来。
插一条重复主键：同学生同课程同批次已有记录，再插就报Duplicate entry。
插一条成绩150分：CHECK约束直接报错，被拦在表外。
这组测试做完，你再回头看这张成绩表的约束设计，会发现它把能防的错误几乎全防住了。剩下的业务校验，比如“未选课不能录入成绩”，已经不是表结构层面能管的，得靠服务代码配合。
我建议每个项目在表结构上线前，都写一批这种“故意犯规”的SQL跑一遍。它们不只是测试用例，更是你给团队后辈留下的数据规则图鉴。
5. 常见问题排查与约束设计自查清单
5.1 约束相关的报错速查表
约束相关的报错几乎是MySQL开发的高频触点，我整理了一份速查表：
| 报错信息 | 触发原因 | 排查方向 |
|---|---|---|
| Duplicate entry 'xxx' for key 'PRIMARY' | 主键冲突 | 检查自增是否失步、是否重复插入 |
| Duplicate entry 'xxx' for key 'uk_email' | 唯一键冲突 | 查业务逻辑、批量导入源数据 |
| Cannot add or update a child row: a foreign key constraint fails | 外键约束失败 | 查父表引用是否存在，字符集/类型是否一致 |
| Cannot add foreign key constraint | 建外键失败 | 按3.2的硬性条件逐条排查 |
| Data too long for column 'name' at row 1 | 字段长度不够 | 检查字符集和实际数据长度 |
| Incorrect integer value: 'abc' for column 'id' at row 1 | 类型不匹配 | 查传入参数、SQL拼接 |
| Check constraint 'chk_score_value' is violated | CHECK约束拦住数据 | 检查取值范围，确认是否走旧数据 |
这些报错有一个共同特点：都在写入的第一时间暴露问题，而不是等脏数据沉淀几个月才引发事故。从这个角度讲，约束越多越早报错，后续运维越轻松。
5.2 字符集、大小写与唯一约束的坑
字符集对约束的影响经常被忽略，但它能制造非常隐蔽的问题。
MySQL的字符串比较依赖排序规则。utf8mb4_general_ci里的_ci表示大小写不敏感，所以唯一约束下'abc'和'ABC'会被判定为重复；utf8mb4_bin是按二进制比较，'abc'和'ABC'是两个不同值，唯一约束就放行。
这就是一个隐藏的业务差异：两张表都建了唯一索引，字符集排序规则不同，同一个字段的重复判断逻辑会不一样。如果业务上客户编号是大小写不敏感的，你就得注意统一排序规则，否则本来该拦截的重复编号，在utf8mb4_bin下顺利入库了。
同理，外键两边的字符集如果不一致，比较时可能全表扫或者直接索引失效。建表统一CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci是个好习惯，至少把80%的字符串类边界问题消掉了。
5.3 导数据时的外键顺序问题
往有外键约束的库里导数据，顺序错了全是外键报错。先导子表后导父表，子表的引用在父表还没数据时就直接被拒。
一条很实用的SQL可以让这个过程省心不少：
SET FOREIGN_KEY_CHECKS = 0; -- 导入顺序随意 SET FOREIGN_KEY_CHECKS = 1;但在开发环境临时导数据可以这么用，生产环境千万别图省事关闭外键检查。关闭后导进来的脏引用不会被拦截，导完再打开外键检查，也不会自动清理已经存在的脏数据。生产导数据一定要用脚本按父表到子表的顺序执行，先学生表再课程表最后成绩表。排序错了，顶多多跑几遍，数据不会坏；外键检查一关，脏数据悄无声息就进来了。
5.4 并发场景下约束引发的死锁
外键和唯一约束在并发插入时有一定概率和锁纠缠在一起。
外键插入时对父表加共享锁，多个事务同时插入相同外键值的子表记录，会在父表同一行上排队。再加上唯一索引插入时遇到重复值需要检查冲突，可能持有插入意向锁再申请其他锁，两个事务互相等待就可能死锁。我见过一个真实案例：并发重试的批量任务往订单明细表里插数据，明细表外键指向订单表，同时订单表又在更新状态，两边加锁顺序不一样，死锁日志里全是外键约束和唯一约束的影子。
解法不是不使用事务和外键，而是注意加锁顺序。让所有并发任务先处理订单表再处理明细表，保持一致的顺序，或者对批量重试任务做幂等控制，减少重复插入带来的锁竞争。排查死锁时，第一步就是看SHOW ENGINE INNODB STATUS里的锁等待关系，判断是否和外键、唯一键的检查路径有关。
5.5 我留下的约束设计自查清单
最后分享一份我在每次表结构评审时都会过的自查清单，你可以直接抄走：
- 每张表是否有明确的主键？主键选择字段是否足够稳定？
- 每个字段的NULL语义是否明确？不能为空的字段是否都带
NOT NULL？ - 状态、标记、时间类字段是否设置了默认值？
- 业务上不应重复的字段是否加了
UNIQUE？大小写敏感性和业务预期一致吗？ - 子表引用父表的关联列是否建立了外键？没有外键的话，应用层是否保证引用完整性？
- CHECK约束是否真的在当前MySQL版本生效？8.0.16以下别依赖它。
- 自增主键是否存在手工插id或导数据后失步的风险？
- 字符串字段的字符集和排序规则是否统一？
- 删除父表数据时，外键级联策略是否符合业务审计需求？
这套清单不是一次性的，应该跟着每次上线走。表结构变更时，把新旧约束对比一眼扫过，很多事故都能提前化解。
在实际项目中积累的几条体会
做表设计做久了会形成一种直觉：约束不是越多越好，而是越准确越好。少一个约束，等于给脏数据留了一扇门；多一个没用的约束，等于给开发流程添了一根刺。所以每加一条约束前，我都会问自己三个问题：这条约束保护的是真实业务还是想象业务？它会不会在正常流程里误伤合法数据？数据出问题的时候，靠这条约束能不能第一时间把问题暴露出来？回答上来了，约束才有意义。
过程中还有一个小技巧可以分享：对约束做变更时，先在测试环境专门造一批绕过约束的脏数据，再试着往生产表结构上套，很多问题在测试阶段就会原形毕露。MySQL的约束其实不复杂，真正复杂的是你对自己业务数据规则的认知。表结构定下来的那一刻，规则就定下来了，之后每一条烂数据都是规则的漏网之鱼。能把约束这张网织得密一点，你后面写业务代码时，就敢少写很多防御性的if。
