大家好，我是小米，今年31岁，一个依旧在技术圈里折腾、爱分享的大哥哥。今天要跟大家聊一个很多人都在面试中遇到的经典问题：

“SQL 约束有哪几种？”

别看问题短，里面的门道可不少。尤其是社招面试官，问这个问题的时候，往往不仅仅想听到你背八股文式的答案，还想听你结合实际场景，说出你对数据库设计的理解。

为了让这个问题更有意思，我给大家讲一个我前阵子面试的真实小故事。

面试现场：约束的灵魂拷问

那天我去面试一家互联网公司，面试官是个看起来很有经验的大哥，聊了几句以后，突然抛出一句：

“小米，你能说说 SQL 里有哪些约束吗？我们在实际项目里是怎么用的呢？”

我当时心里一紧。这个问题看似简单，其实就是一个“送命题”——要么你只背几个关键词，被打入“只会死记硬背”的分类；要么你能说清楚背后的设计哲学，面试官立马会觉得你是个能解决实际问题的人。

于是，我深吸一口气，开始从“约束”的本质聊起。

什么是约束？——给数据上保险

我对面试官说：

“约束，其实就是数据库帮我们加的保险。它规定了表里的数据必须满足某些规则，否则就不允许存进去。目的只有一个：保证数据的正确性和一致性。”

面试官点点头，我接着举了个例子：

想象一下，你在做一个电商系统，如果没有约束：

  • 用户可以注册一个没有手机号的账号；
  • 商品库存可以是负数；
  • 订单可以没有关联的用户；
  • 同一个邮箱可以注册 100 个账号。

是不是一想就很可怕？

而约束，就是用来防止这些“数据灾难”的。

SQL 约束的六大门派

说到具体的约束，其实 SQL 里有六大“门派”。我用江湖的方式给大家捋一遍：

1. NOT NULL(非空约束)——“最基本的规矩”

这个约束就像家规里的第一条：不能缺胳膊少腿。

比如，用户表里的 username，你不可能让它为空吧？否则系统里就会出现一堆匿名用户，管理起来乱七八糟。

MySQL社招面试题：SQL 约束有哪几种？_外键

一旦设置了 NOT NULL，你插入数据时必须提供值，否则报错。

2. UNIQUE(唯一约束)——“一号身份牌”

这个就像身份证，一个人只能有一个号码。

比如用户的邮箱，必须唯一。如果允许重复，那 A 用户和 B 用户都用同一个邮箱，你还能分得清谁是谁吗？

MySQL社招面试题：SQL 约束有哪几种？_外键_02

有意思的是，UNIQUE 可以跟 NULL 搭配。一个字段如果是 UNIQUE 但允许 NULL，那可以插入多条 NULL(因为数据库认为 NULL ≠ NULL)。这个小坑面试官常常会考。

3. PRIMARY KEY(主键约束)——“江湖的掌门”

主键约束就更霸气了，它既不能为 NULL，也必须唯一。

每张表都应该有一个主键，它就是这张表的“身份证号码”。

比如用户表里的 id：

MySQL社招面试题：SQL 约束有哪几种？_外键_03

有了主键，数据库就能快速定位到一条唯一的数据记录。

4. FOREIGN KEY(外键约束)——“江湖的盟约”

外键约束是最能体现“江湖规则”的。它规定了一种表与表之间的关系。

比如，订单表里的 user_id，就应该是用户表 id 的外键。这样才能保证：

  • 插入订单时，必须有对应的用户存在；
  • 删除用户时，得先考虑如何处理他的订单。

MySQL社招面试题：SQL 约束有哪几种？_数据库_04

当然，在大规模高并发系统里，很多公司会减少外键的使用，用应用层逻辑来维护关联，因为外键对性能和扩展性会有影响。这点如果在面试时顺便提一下，面试官往往会心一笑。

5. CHECK(检查约束)——“规矩的底线”

CHECK 就像家里的规矩里加的一句“只许正能量，不许胡闹”。

比如，用户的年龄必须大于 0：

MySQL社招面试题：SQL 约束有哪几种？_外键_05

不过要注意的是，MySQL 在 8.0 之前几乎不真正执行 CHECK，只是语法上允许。面试的时候提到这个小细节，会让你显得很“有经验”。

6. DEFAULT(默认值约束)——“贴心的小助手”

DEFAULT 就像系统帮你准备的默认设置。

比如用户注册时没有填头像，就给他一个默认头像；注册时间没传，就用当前时间。

MySQL社招面试题：SQL 约束有哪几种？_主键_06

这样能减少很多麻烦，还能保证数据完整性。

约束的组合拳：江湖高手的修炼方式

说到这里，我没有停，而是补充了一点实战经验：

很多时候，单独用一个约束不够，真正的高手是会“组合拳”的。比如：

  • 用户表的 id：PRIMARY KEY + AUTO_INCREMENT
  • 商品表的 sku：NOT NULL + UNIQUE
  • 订单表的 user_id：NOT NULL + FOREIGN KEY

这样设计下来，不仅能保证数据的严谨性，还能让逻辑关系更清晰。

约束之外：工程实践中的取舍

面试官听到这时，突然问了一句：

“那你觉得在真实的项目里，我们要不要都用上这些约束？”

这个问题，其实是考察你有没有实战经验。

我回答说：

在小型系统里，完全可以依赖数据库约束来保证数据的正确性。

但在大型分布式系统里，有时候会适度放弃外键、CHECK 这种约束，而改由应用层来控制。原因主要有三点：

  • 性能：外键、CHECK 会增加数据库负担；
  • 灵活性：微服务化后，表的依赖关系可能会拖慢开发；
  • 可维护性：应用层代码更容易做复杂逻辑，比如跨表的校验。

不过，像 NOT NULL、PRIMARY KEY、DEFAULT 这种轻量级约束，还是必须保留的，它们几乎不会带来额外负担。

复盘：如何回答面试官

我总结了一下这个问题的答题思路，分享给大家：

  • 先总述：约束是保证数据正确性和一致性的规则。
  • 再分类：NOT NULL、UNIQUE、PRIMARY KEY、FOREIGN KEY、CHECK、DEFAULT 六种。
  • 加例子：结合用户、订单、电商场景，解释每种约束。
  • 谈实践：说明约束在大规模项目里的取舍和注意点。
  • 补细节：比如 UNIQUE + NULL 的坑、MySQL 8.0 之前 CHECK 的限制。

这样一套流程走下来，不仅展示了知识点，还体现了思考和经验，面试官基本就能被你“拿下”。

写在最后

回到面试那天，面试官听完我的回答，笑着说：“小米，你这个思路很全面，看来平时是真做过项目的。”

虽然那次面试我最终没去那家公司，但我觉得这道题真的很经典。它表面是一个知识点，背后考察的却是你对数据库设计哲学的理解。

如果你下次面试再遇到这个问题，不妨按照我分享的这个思路去回答。记住：别死记硬背，把知识讲成故事，把经验讲成思路，面试官才会真正认可你。

END

好了，今天的分享就到这。

我是小米，一个喜欢分享技术的31岁程序员。如果你喜欢我的文章，欢迎关注我的微信公众号“软件求生”，获取更多技术干货！