我最早对 MySQL 约束有深刻体会，不是因为学会了约束，而是因为接手了一个没有约束的老系统。那张订单表里什么都能插进去：订单状态可以写成"已付款"也可以写成"已付歀"，金额可以是负数，同一个用户居然能同时存在两条"主身份"记录。那段时间我每天的工作就是从脏数据里猜业务真相，后来实在受不了，花了两周把所有表结构重新设计了一遍，该加的主键、外键、唯一键、CHECK 全部补上，从那之后数据质量才真正"稳"下来。
这篇文章想把 MySQL 约束这件事从头到尾讲透。内容不只是"五种约束怎么写"，而是把它当成一套完整的表结构设计方法论：约束解决什么问题、每种约束的底层原理、最容易踩的坑、以及生产环境里到底怎么用才不翻车。适合有基本 SQL 基础、正在学表结构设计的开发同学，也适合那些被历史脏数据折磨、想系统重建数据规则的运维或后端工程师。看完之后，你能动手设计出一套"能自己扛住错误数据"的表结构，而不是把校验全指望业务代码。
1. 约束到底是干什么的：先对齐底层认知
1.1 数据完整性到底指什么
先问一个问题：为什么 MySQL 需要约束？表面答案是"限制能插入的数据"，但底层其实是四个字——数据完整性。数据库领域把完整性分成四层：
- 实体完整性：每一行都要能被唯一识别，对应的就是主键约束。没有主键的表在 InnoDB 里其实也会有个隐式主键，但你自己不定义，后续做关联、做同步、做数据订正都会非常痛苦。
- 域完整性：每一列的值必须落在合法的"域"里。比如年龄不能是负数、邮箱格式要大致对、状态字段不能乱填，对应 NOT NULL、CHECK、DEFAULT 这些机制。
- 参照完整性：A 表引用 B 表的数据，B 表那条记录必须真实存在，而且不能随便删。这就是外键约束做的事。
- 用户定义完整性：业务自己的规则，比如"同一用户不能重复参与同一个活动"、"结束时间必须晚于开始时间"，通常用唯一约束和 CHECK 组合实现。
约束不是一个孤立概念，它是数据库替你守住这四层完整性的工具。把它想成仓库门口的保安：货不对板不让进，标签重复不让进，引用不到上游单据的也不让进。仓库管理得越严，后面出账、盘点、追溯就越省心。
1.2 五大约束的功能矩阵
MySQL 官方语境下，约束主要指这五类：NOT NULL、UNIQUE、PRIMARY KEY、FOREIGN KEY、CHECK。它们的核心作用和对索引的影响各不相同，很多人搞混，我直接给一张对照表：
| 约束类型 | 保证的完整性 | 核心作用 | 是否自动建索引 |
|---|---|---|---|
| NOT NULL | 域完整性 | 列不允许为 NULL | 否 |
| UNIQUE | 实体完整性 / 用户定义完整性 | 列或列组合的值不重复 | 是，唯一索引 |
| PRIMARY KEY | 实体完整性 | 唯一标识一行记录 | 是，聚簇索引 |
| FOREIGN KEY | 参照完整性 | 子表引用父表的合法记录 | 是，若列上无索引会自动创建 |
| CHECK | 域完整性 / 用户定义完整性 | 值必须满足布尔表达式 | 否 |
这张表建议存一下，面试也常考。注意 UNIQUE 和 PRIMARY KEY 都会建索引，所以约束在某些场景下还能"顺带加速查询"；但 NOT NULL 和 CHECK 纯粹是数据规则，对查询性能没有直接影响，别指望用它们优化慢 SQL。
1.3 约束和索引为什么总被搞混
很多人以为"唯一约束等于唯一索引"，严格说不完全对。约束是规则，索引是实现规则的手段之一。MySQL 里 UNIQUE 在创建时确实会附带一个唯一索引，删掉索引就等于删掉约束；外键则反过来，它需要一个索引去加速"扫描子表是否有引用"，如果对应列本来没有索引，InnoDB 会自动帮你建一个普通索引。
这意味着什么？意味着你建外键时，即使没主动建索引，MySQL 也会默默建一个。在高并发写入场景下，这个自动索引会占用额外空间、拖慢写入速度，这也是后面说的"外键不是不能用，但要慎重用"的原因之一。掌握约束与索引的关系，排查慢查询时思路会清晰很多。
2. 五大约束逐个击破：语法、行为与易错点
2.1 NOT NULL：NOT NULL 管不住空字符串
NOT NULL 是最简单的约束，语法上就是在列定义后面加一排：
CREATE TABLE t_user ( id INT PRIMARY KEY, nickname VARCHAR(50) NOT NULL );但很多人对它有个误解，以为加了 NOT NULL 之后，空字符串就插不进去了。其实''和NULL在 MySQL 里是两种完全不同的语义：NULL表示"未知、尚未赋值"，''表示"已经赋了一个空值"。所以nickname = ''完全合法，只有nickname = NULL才会报错。
这个区别在业务上非常关键。曾经有个项目要统计用户昵称填写率，代码里一直用WHERE nickname IS NULL去查，结果发现好多记录写的是''，统计直接偏了。所以设计的时候要跟业务方对齐：这个字段是"必填但可能为空内容"还是"暂不知晓"？前者用DEFAULT ''，后者才用允许 NULL。
另外，强烈建议把 NOT NULL 和 DEFAULT 成对设计。比如status TINYINT NOT NULL DEFAULT 1，既保证插入时不会因为漏字段而报错，又保证数据是可控的。光有 NOT NULL 没有默认值，应用层一旦漏传就会整条 SQL 失败，线上很容易变成事故。
2.2 UNIQUE：唯一性与 NULL 的微妙关系
UNIQUE 约束要求列或列组合的值不重复，语法：
CREATE TABLE t_user ( id INT PRIMARY KEY, email VARCHAR(100), UNIQUE KEY uk_user_email (email) );这里有个极其容易踩坑的地方：UNIQUE 约束允许多个 NULL 共存。也就是说，你可以插入两条email = NULL的记录，MySQL 不会报错。这是标准 SQL 的行为，因为 NULL 不等于任何值，包括 NULL 自己。但这就给业务埋了一个雷：如果业务想表达"邮箱要么不填，一旦填了就必须唯一"，用普通 UNIQUE 是成立的；但如果业务想表达"所有用户要么不填，填了的必须唯一，但历史上已经有多条 NULL"，那就得靠其他手段兜底。
复合唯一约束也很常用，比如"一个用户对同一个商品只能有一条收藏记录"：
CREATE TABLE t_favorite ( id INT PRIMARY KEY, user_id INT NOT NULL, product_id INT NOT NULL, UNIQUE KEY uk_user_product (user_id, product_id) );组合唯一的意义是"组合值不能重复"，不是"每列各自不能重复"。
2.3 PRIMARY KEY：为什么一张表只有一个
主键约束是实体完整性的核心，一张表只能有一个主键。它可以由单列组成，也可以由多列组成（复合主键）。从语法上看，主键和UNIQUE + NOT NULL几乎等价，但有几处本质区别：
- 主键自动成为 InnoDB 的聚簇索引，数据的物理存储顺序按主键组织。
- 外键引用时，默认引用目标是主键或唯一键。
- 主键只有一个，唯一键可以有多个。
- 主键优先作为复制、日志、同步的定位依据。
关于主键类型，我个人的生产经验是：坚决推荐自增 BIGINT，不推荐业务主键或 UUID 主键。自增主键写入顺序和聚簇索引顺序一致，能减少页分裂；UUID 主键随机性太强，插入时会导致聚簇索引频繁页分裂，产生大量碎片，写入性能明显下降。8.0 里虽然可以用 UUID 转二进制存储，但能不用还是不用。
还要注意自增主键并不保证连续，事务回滚后会跳号，这个不是 Bug 而是设计如此。如果有人纠结"主键怎么缺号了"，把文档甩给他就行。
2.4 FOREIGN KEY：强大的参照完整性，但别急着用
外键约束保证子表引用父表的记录必须存在，语法涉及的东西比较多：
CREATE TABLE t_order ( id INT PRIMARY KEY, user_id INT NOT NULL, ... CONSTRAINT fk_order_user FOREIGN KEY (user_id) REFERENCES t_user (id) ON DELETE RESTRICT ON UPDATE CASCADE );这里是重点，ON DELETE和ON UPDATE的行为有五种，容易记混：
| 行为 | 父表删除/更新时子表表现 | 适用场景 |
|---|---|---|
| RESTRICT | 有子表引用则拒绝操作 | 不允许删有引用的父记录 |
| NO ACTION | 和 RESTRICT 等价，即时检查 | 同上 |
| CASCADE | 同步删除/更新子表记录 | 级联清理明细数据 |
| SET NULL | 子表外键列置为 NULL | 保留明细但解除引用 |
| SET DEFAULT | 子表外键列设为默认值 | InnoDB 实际不执行该动作，不推荐 |
MySQL 的 InnoDB 引擎才支持外键，MyISAM 建了也不会生效。而且外键并不是免费的午餐：每次在子表插入或更新时，InnoDB 都要检查父表是否存在对应记录，意味着额外读；父表删除或更新时，需要扫描子表索引，可能引发行锁竞争。在高并发系统里，外键往往是死锁和慢操作的来源之一。所以我建议：内部管理系统、数据一致性要求极高的场景可以放心用外键；高并发互联网应用谨慎使用，甚至不用物理外键，这个后面专门开一节讲。
2.5 CHECK：从"摆设"到"真校验"的进化
CHECK 约束是最容易被忽视、也最容易出问题的约束。它的作用是限制列值必须满足某个布尔表达式：
CREATE TABLE t_user ( id INT PRIMARY KEY, age INT, salary DECIMAL(10,2), CONSTRAINT ck_user_age CHECK (age >= 0 AND age <= 120), CONSTRAINT ck_user_salary CHECK (salary >= 0) );还可以写多列之间的约束，比如"结束时间必须晚于开始时间"：
CONSTRAINT ck_plan_date CHECK (end_date > start_date)但这里必须强调一个历史大坑：MySQL 8.0.16 之前，CHECK 约束虽然语法合法、SHOW CREATE TABLE 里也显示，但根本不会执行。也就是在 5.7 上建了 CHECK，你照样能插入 age = -1，数据不会报错。很多人因此骂 MySQL 是假的 CHECK。真正的强制执行从 8.0.16 开始才落地，我建议生产环境用 8.0.16 以上版本，并且确认SHOW CREATE TABLE里能看到约束，再相信它真的会拦截非法数据。
CHECK 比 ENUM 类型更灵活：ENUM 只能枚举合法值，新增一个枚举值要改表结构；CHECK 的条件可以写成status IN (...),也能写范围、比较表达式。从 8.0 开始，能上 CHECK 就别再用 ENUM 硬撑了。
3. 从零设计三张表的约束：一次完整实操
3.1 需求与实体关系
光讲语法太虚，我带你把一套三张表的约束从零设计一遍。场景是一个轻量内容系统：用户（t_user）、文章（t_article）、评论（t_comment）。
- 用户：id、手机号（登录标识）、昵称、年龄、创建时间。
- 文章：id、作者 user_id、标题、正文、状态（草稿/已发布/已下线）、发布时间。
- 评论：id、文章 article_id、评论者 user_id、内容、创建时间。
表关系很简单：用户 1 对 N 文章，用户 1 对 N 评论，文章 1 对 N 评论。但关系简单不代表约束简单，设计的时候要把每一步业务规则想清楚。
3.2 约束设计顺序：先业务规则后写 SQL
我建表有个固定顺序，先不在键盘上动手，而是把下面的问题过一遍：
- 哪些列能唯一确定一行？哪个做主键？是否需要复合主键？（本案例都用单列自增 id）
- 哪些列业务上要求唯一？手机号必须唯一，昵称是否唯一要跟产品确认。
- 哪些列不允许为空？哪些列必须有默认值？
- 哪些列会被其他表引用？比如 user_id、article_id 是不是要建外键？
- 哪些列的值需要满足范围或枚举？状态字段、年龄字段用不用 CHECK？
这套自问做完，表结构基本就八九不离十了。约束设计的本质是"把业务规则前置到数据库层"，而不是等应用层漏校验了再补。
3.3 完整建表语句（附注释）
下面是我实际会写出来的建表语句：
CREATE TABLE t_user ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键', phone VARCHAR(20) NOT NULL COMMENT '手机号，登录账号', nickname VARCHAR(64) NOT NULL COMMENT '昵称', age TINYINT UNSIGNED NOT NULL DEFAULT 0 COMMENT '年龄', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (id), UNIQUE KEY uk_user_phone (phone), CONSTRAINT ck_user_age CHECK (age >= 0 AND age <= 120) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表'; CREATE TABLE t_article ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键', user_id BIGINT UNSIGNED NOT NULL COMMENT '作者ID', title VARCHAR(200) NOT NULL COMMENT '标题', content TEXT NOT NULL COMMENT '正文', status TINYINT NOT NULL DEFAULT 0 COMMENT '状态：0草稿 1已发布 2已下线', published_at DATETIME DEFAULT NULL COMMENT '发布时间', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (id), KEY idx_article_user (user_id), CONSTRAINT fk_article_user FOREIGN KEY (user_id) REFERENCES t_user (id) ON DELETE RESTRICT, CONSTRAINT ck_article_status CHECK (status IN (0, 1, 2)) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='文章表'; CREATE TABLE t_comment ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键', article_id BIGINT UNSIGNED NOT NULL COMMENT '文章ID', user_id BIGINT UNSIGNED NOT NULL COMMENT '评论者ID', content VARCHAR(1000) NOT NULL COMMENT '评论内容', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '评论时间', PRIMARY KEY (id), KEY idx_comment_article (article_id), CONSTRAINT fk_comment_article FOREIGN KEY (article_id) REFERENCES t_article (id) ON DELETE CASCADE, CONSTRAINT fk_comment_user FOREIGN KEY (user_id) REFERENCES t_user (id) ON DELETE RESTRICT ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='评论表';几个设计决策说明一下：
t_user.id用BIGINT UNSIGNED，生产环境用户量大，INT 很容易不够用，直接一步到位。t_article.user_id建普通索引，既加速查询，也让外键检查不拖后腿。t_comment对article_id用ON DELETE CASCADE，文章删了评论一起删，符合业务直觉；对user_id用RESTRICT，用户被引用时禁删，保护审计链路。- 状态字段用
TINYINT + CHECK，比 ENUM 灵活，后续加状态不用改表。
3.4 用 INSERT 测试约束是否真的生效
建的约束不是用来好看的，写完表我习惯立刻跑几条非法 SQL 验证：
-- 违反非空约束 INSERT INTO t_user (phone, nickname, age) VALUES (NULL, '张三', 20); -- ERROR 1048: Column 'phone' cannot be null -- 违反唯一约束 INSERT INTO t_user (phone, nickname, age) VALUES ('13800138000', '李四', 21); -- ERROR 1062: Duplicate entry '13800138000' for key 't_user.uk_user_phone' -- 违反 CHECK 约束 INSERT INTO t_user (phone, nickname, age) VALUES ('13800138001', '王五', -5); -- ERROR 3819: Check constraint 'ck_user_age' is violated -- 违反外键约束 INSERT INTO t_article (user_id, title, content) VALUES (99999, '测试', '内容'); -- ERROR 1452: Cannot add or update a child row: a foreign key constraint fails这四条验证跑完，约束算真正生效了。很多同事建完表不验证，等应用层测试报错才发现约束建错地方，白白浪费一整天。
4. 约束的日常运维：查看、修改与删除的正确姿势
4.1 查看约束的三种途径
实际维护中你经常会遇到"不知道表上有什么约束"的情况，尤其接手别人系统时。我常用的查看方式有三个：
第一种，最直观，直接看建表语句：
SHOW CREATE TABLE t_article;它会把所有约束定义原样打印出来，适合人工评审。
第二种，查系统库，适合写脚本巡检：
SELECT TABLE_NAME, CONSTRAINT_NAME, CONSTRAINT_TYPE FROM information_schema.TABLE_CONSTRAINTS WHERE TABLE_SCHEMA = 'your_db';第三种，细看约束对应的列和外键引用关系：
SELECT TABLE_NAME, COLUMN_NAME, CONSTRAINT_NAME, REFERENCED_TABLE_NAME, REFERENCED_COLUMN_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 't_comment';信息碎片都在 information_schema 里，把它当成你的"约束查询入口"，比肉眼翻表结构高效得多。
4.2 追加与删除约束的 ALTER TABLE 语法
表已经上线了再补约束，是 DBA 的日常。语法分成几类：
-- 追加主键 ALTER TABLE t_user ADD PRIMARY KEY (id); -- 追加唯一约束 ALTER TABLE t_user ADD UNIQUE KEY uk_user_phone (phone); -- 追加外键约束 ALTER TABLE t_comment ADD CONSTRAINT fk_comment_article FOREIGN KEY (article_id) REFERENCES t_article(id) ON DELETE CASCADE; -- 追加 CHECK 约束 ALTER TABLE t_user ADD CONSTRAINT ck_user_age CHECK (age >= 0 AND age <= 120); -- 修改列为 NOT NULL ALTER TABLE t_user MODIFY COLUMN phone VARCHAR(20) NOT NULL;删除约束的姿势要按类型区分：
-- 删除主键 ALTER TABLE t_article DROP PRIMARY KEY; -- 删除唯一约束（本质是删索引） ALTER TABLE t_user DROP INDEX uk_user_phone; -- 删除外键约束 ALTER TABLE t_comment DROP FOREIGN KEY fk_comment_article; -- 删除 CHECK 约束 ALTER TABLE t_user DROP CHECK ck_user_age;这里有个小坑：如果表上有自增主键，直接 DROP PRIMARY KEY 会报错，得先把列的自增属性去掉：
ALTER TABLE t_user MODIFY COLUMN id BIGINT UNSIGNED NOT NULL; ALTER TABLE t_user DROP PRIMARY KEY;还需要注意 DROP FOREIGN KEY 时，如果外键曾自动创建了索引，约束删除后索引不会自动删，需要单独 DROP INDEX。很多人删了外键发现索引还在，其实就是这个原因。
4.3 大表变更要小心锁与复制延迟
加约束在大表上不是小事。尤其在 5.7 上，很多 ALTER TABLE 操作会重建表，期间对表的 DML 会被阻塞，线上可能出现"连接数打满"的连锁反应。8.0 对部分操作做了在线 DDL 优化，但也不是所有操作都天然安全。
我的建议是三个字：先看量。确认要操作的表有多大，如果超过百万行，先把变更放到维护窗口，同时观察主从延迟。比如加 CHECK 约束时，MySQL 需要扫描全表校验已有数据，这个扫描在从库也会执行，大表上的耗时不能忽略。
如果确实需要在业务高峰期操作，可以考虑用工具软变更（比如 gh-ost、pt-osc），它们通过复制流把表结构变更拆成小事务执行，能显著降低锁的影响。但这类工具本身也很考验运维能力，团队不熟就不要贸然上。
5. 我在生产环境踩过的约束相关的五个坑
5.1 大表外键导致死锁与慢删除
有一年我维护过一个订单系统，订单主表、订单明细表、操作日志表之间通过外键串成一条链。平时写入量不大，看着挺美好。直到做一次大促后的历史数据清理，要按时间删除一批老订单，结果线上 DELETE 慢得像乌龟爬，还频繁报死锁。
排查链路是这样的：先看慢查询日志，发现耗时全在 DELETE 订单主表那条语句上；接着SHOW ENGINE INNODB STATUS看死锁日志，发现锁等待集中在明细表和日志表；最后用KEY_COLUMN_USAGE一查，发现这些子表都带ON DELETE CASCADE外键。删除一条主订单，InnoDB 要逐个去子表索引里扫描匹配记录，索引一旦不完善，锁范围就扩大，死锁自然就来了。
处理办法是把物理外键去掉，改成应用层事务里显式删除明细和日志，同时补偿一个定时对账任务。这样既能保证最终一致性，又能把删除操作拆分到可控粒度，问题立刻缓解。你要问我现在怎么选，我依然坚持：小项目和内部系统随便用外键；高并发、大表、频繁批量删除的系统，别让外键成为性能瓶颈。
5.2 ON DELETE CASCADE 一删删一片
另一个外键事故发生在一次数据订正时。运营发现一批测试数据要清理，我直接执行了DELETE FROM t_user WHERE id IN (...)，想着评论表的外键是 CASCADE，文章表的外键也有 CASCADE，应该"清理得很干净"。
结果删完发现，这个用户的所有历史文章、评论连带全部没影了，连审计需要的原始记录都没留下。问题的根源不是 CASCADE 本身，而是我低估了级联删除的"传染性"。删除动作会像涟漪一样扩散到所有引用它的子表、孙表，一旦范围判断失误，数据就找不回来了（没有备份的话）。
从那次之后，我对线上删除立了三条规矩：能逻辑删除绝不物理删除；物理删除前必须执行 SELECT COUNT 验证影响行数；涉及 CASCADE 的删除必须多一层审批确认。级联约束好用，但它是高危工具，不是给你随便玩的。
5.3 5.7 里 CHECK 约束静默失效
还有一次接手一个老项目，建表时写了 CHECK 约束，但线上数据却出现了 age = -3 的"奇迹"。刚开始我以为 INSERT 语句没走这套逻辑，后来才发现 MySQL 版本是 5.7，CHECK 约束在 5.7 里只是语法上被接受，实际执行时直接被忽略。SHOW CREATE TABLE 能看到约束名，但它就是个纸老虎。
这类"静默失效"最可怕，因为你看不出结构有问题，但它根本没在保护你。排查方式很简单：确认版本SELECT VERSION();，然后故意插入一条非法数据试试，如果 INSERT 成功，说明约束没生效。
这也提醒我：升级 MySQL 到 8.0.16 以上之后，一定要把历史表里的 CHECK 约束检查一遍，因为"从忽略到生效"这个转变可能导致原本能插入的数据在新版本被拒绝，应用层需要配合调整。
5.4 UNIQUE + NULL 的组合陷阱
用户表加过唯一约束，要求邮箱字段"要么不填，填了就不能重复"。用 UNIQUE 约束建好之后，测试阶段一直正常。结果导入历史数据时，ETL 工具把空值统一写成了空字符串''，而不是 NULL。两个用户都是''，直接触发唯一约束冲突，整个导入流程报错。
这个案例的关键在于：空字符串是"值"，两个空字符串重复，UNIQUE 当然拦；NULL 才是"未知"，UNIQUE 放行。解决的方法是统一规则：业务上表示"没填写"的字段全部走 NULL，不要在应用层或 ETL 层把空值转成''。
如果字段本身已经存在大量''历史数据，且不能清空，那唯一约束就很难加。要么把''统一 UPDATE 成 NULL 后再加约束，要么用生成列做条件唯一索引。后者在 8.0.13+ 可以用函数索引实现，但复杂度更高，能不改旧数据就尽量改数据。
5.5 大字段加唯一索引直接报错
有一个评论系统想给"评论内容"加唯一约束防重复提交（实际这个需求不合理，但当时需求方坚持），结果建索引时报错：ERROR 1071: Specified key was too long; max key length is 3072 bytes。
原因不难理解：InnoDB 在 DYNAMIC 行格式下，索引键最大 3072 字节；utf8mb4 一个字符最多 4 字节，VARCHAR(1000) 最大可能占用 4000 字节，直接超限。就算变成 VARCHAR(768) 也很接近上限，不建议赌。
最终方案是给唯一索引加前缀长度，只取前 100 或 150 个字符做唯一判断。但前缀唯一有个副作用：只要前缀相同就判定重复，可能误伤内容不同但前缀相同的记录。所以防重复这种需求，最稳妥还是应用层哈希列 + 唯一约束组合：建一个 content_hash CHAR(64) 列存 SHA256，再对哈希列加唯一索引。这个思路同样适用于那些"字段太长不能直接加唯一索引"的场景。
6. 约束设计的最佳实践清单：把规则写进数据库
6.1 约束命名规范要早定
约束没有统一命名规范的库，维护起来非常痛苦。我见过id_2、key_1这种系统自动生成的约束名，出问题根本不知道它是干嘛的。从第一天就定一套规则，成本几乎为零，收益长期显著：
- 主键：
pk_表名 - 唯一约束：
uk_表名_列名，组合唯一用下划线连列名 - 外键：
fk_表名_引用表名或fk_子表_父表 - CHECK：
ck_表名_业务含义
建约束时都指定名字，千万别空着让 MySQL 自动取。之前排障时深夜去查一个外键叫什么，最后靠系统表翻半天才定位到，那个滋味不想体验第二次。
6.2 物理外键用不用，看完这组对比再决定
物理外键是一个争议话题，我的观点可以浓缩成一张表：
| 维度 | 用物理外键 | 不用物理外键 |
|---|---|---|
| 数据一致性 | 数据库层强制，最可靠 | 靠应用层事务与补偿 |
| 开发效率 | 建表稍繁琐，但约束内聚 | 灵活，但代码要更严谨 |
| 高并发写入 | 每次写有额外检查开销 | 开销更小，扩展更自由 |
| 分库分表 | 基本不支持跨库外键 | 不受影响 |
| 批量删除 | 级联和锁风险高 | 可控但是要自己删子表 |
我的个人倾向是：团队规模小、系统逻辑集中、数据一致性要求高，放心用外键；大流量互联网业务、频繁迭代、表拆分接近分库分表场景，就别让外键捆住手脚，把参照完整性逻辑放到服务层去保证，同时用定期对账兜底。不要盲目吹某一个选择，站在团队实际情况上做决定。
6.3 软删除场景下唯一约束怎么设计
这是个很高频的问题：用户表有唯一约束在用户名字段上，产品要求逻辑删除（保留记录，不物理删），但删掉的数据还占着 username，新用户注册时始终提示"用户名已存在"。
常见方案是加一个deleted_at字段参与唯一索引：
ALTER TABLE t_user ADD COLUMN deleted_at DATETIME NOT NULL DEFAULT '1970-01-01 00:00:00' COMMENT '删除时间，未删除则为初始值'; ALTER TABLE t_user DROP INDEX uk_user_name, ADD UNIQUE KEY uk_user_name_deleted (username, deleted_at);未删除的用户deleted_at统一等于初始值，用户名唯一性生效；删除时把deleted_at更新为当前时间戳，这样同名的两个不同删除记录时间戳不同，不会冲突，新用户也能用原来的用户名。有一点千万注意：deleted_at不能允许 NULL，否则多个 NULL 在唯一索引里还是会互不冲突。
8.0.13 之后也可以考虑函数索引，比如只对未删除记录建唯一索引，但对运维要求高一些。能看懂原理的团队用第一种方案最稳。
6.4 上线前用这几条 SQL 巡检约束
最后分享一个我每次发版前都会跑的巡检思路，用系统表把数据库里"保护力度"一目了然：
-- 查看所有表是否有主键 SELECT TABLE_SCHEMA, TABLE_NAME FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME NOT IN ( SELECT TABLE_NAME FROM information_schema.TABLE_CONSTRAINTS WHERE CONSTRAINT_TYPE = 'PRIMARY KEY' ); -- 查看所有外键及级联策略 SELECT TABLE_NAME, CONSTRAINT_NAME, DELETE_RULE, UPDATE_RULE FROM information_schema.REFERENTIAL_CONSTRAINTS WHERE CONSTRAINT_SCHEMA = 'your_db';这套 SQL 不需要额外工具，复制到客户端就能用。上线前花十分钟扫一遍，比出事故后加索引、补约束省太多精力。我后来把这段逻辑写进定时巡检报告，每周自动跑一次，谁往库里加了没有约束的表，第一时间就能发现。
约束这件基础功，平时看不见摸不着，但真的到了数据出问题那天，你才会知道它替你挡了多少灾难。别嫌麻烦，把规则写进数据库，是给未来的自己省时间。
