做开发这些年，我一直感慨：很多人在写 SQL 时，对数据库 constraint 的态度特别随意。明明是能帮你省下无数 bug 的东西，却被当成累赘。我见过最极端的例子：一个团队上线前把外键全删了，理由是“影响性能”。结果呢？两个月后数据乱成一锅粥，订单表和用户表对不上，查问题得翻三天日志。你说这怪谁？其实数据库 constraint 就像家门上的锁，平时觉得碍事，真丢了东西才知道心疼。
先聊聊最常见的 NOT NULL。这玩意儿看着简单，但坑特别多。我有个朋友做电商系统，用户注册时邮箱字段没设 NOT NULL，结果业务方说“有些人可能没邮箱”。后来数据灌进来，一堆空值，查询用户信息时程序动不动就崩。为什么？因为代码里根本没处理 null 的情况。NOT NULL 不只是数据库的规则，它是在告诉你：这个字段必须有值，别给我留后路。设了它，代码逻辑就能少写一堆 if 判断。而且，NOT NULL 还能让索引更高效，因为 NULL 值在 B+ 树里处理起来比较麻烦。所以，能用 NOT NULL 的地方，千万别手软。
UNIQUE 约束也是个大杀器。我见过一个社交 App，用户昵称没设 UNIQUE，结果两个用户注册了同一个昵称，系统直接崩溃。后来加了 UNIQUE，问题解决。但 UNIQUE 也有讲究，比如联合唯一键。你有个订单表，订单号和商品 ID 联合起来唯一，那就得用 UNIQUE(orderid, productid)，而不是分开设。为什么？因为分开设的话，同一个订单里能出现两个相同商品，这不符合业务逻辑。还有，UNIQUE 对 NULL 的处理跟你想的不一样：MySQL 里，UNIQUE 允许多个 NULL 值，因为 NULL 不等于任何值。这点一定要记清楚，不然调试时会抓狂。
再说说 PRIMARY KEY，这玩意儿是表的灵魂。很多人喜欢用自增 ID 当主键，省事儿。但有时候业务上需要更自然的主键，比如用户表的手机号。把手机号设为主键，查询时不用再走一次索引，性能反而更好。不过要注意：主键最好是稳定不变的，别用会变的值，比如用户名。用户改了名，主键就得跟着改，关联表都要同步，后果堪比多米诺骨牌。还有，主键字段要尽量短，因为 InnoDB 的聚簇索引是按主键组织的，主键越长，二级索引就越大，磁盘 I/O 越多。
FOREIGN KEY 这玩意儿争议最大。很多人嫌它拖慢插入和更新速度，索性不用。但你要明白，外键是保证数据完整性的一道防线。没有外键，你删了某个用户，订单表里还残留那个用户的 ID，查出来就是幽灵数据。我有个客户做金融系统，死活不用外键，结果对账时发现一笔交易关联的用户 ID 在用户表里不存在，花了三天才追溯到是手动删数据时漏了。当然，外键确实有性能开销，但可以通过软删除或触发器来模拟外键行为，既保持完整性又提升性能。别因为怕麻烦就把它废了。
CHECK 约束是个被严重低估的东西。很多数据库都支持，但实际用得少。其实 CHECK 能帮你做很多事，比如限制年龄必须在 0 到 150 之间，或者订单金额必须大于 0。这些逻辑写在数据库里，比写在应用层更可靠，因为应用层可能换人、改代码，而数据库规则基本不变。我有个做库存系统的朋友，用 CHECK 约束保证库存量不能为负，结果再也没有出现超卖。不过要注意：MySQL 的 CHECK 约束在 8.0 之前是摆设，需要用触发器模拟。使用前先查文档，别白费力气。
DEFAULT 约束看着不起眼，但用好了能省很多事。比如创建时间字段，可以直接设 DEFAULT CURRENT_TIMESTAMP，这样插入时就不用手动填时间了。还有状态字段，比如订单状态，设个 DEFAULT 'pending'，新订单进来自动就是待处理状态。这样既减少代码量，又能避免漏填。不过要小心：DEFAULT 值最好与业务逻辑一致，别设个没有意义的默认值。比如性别字段设 DEFAULT '男'，但业务里可能有未选择的情况，这时应该用 NULL 或空字符串，否则统计时会出乌龙。
聊聊性能和实践。很多人觉得 constraint 多了会影响性能，其实影响微乎其微。数据库的约束检查是 O(1) 或 O(log n) 的，比在应用层写一堆 if‑else 快得多。而且，约束能帮你尽早发现数据问题，而不是等到报表出来才发现。我建议的做法是：先设计好所有约束，再考虑性能调优。如果某个约束真的成了瓶颈，比如外键导致大量插入变慢，可以通过缓存或批量插入来缓解，而不是一刀切地删掉。记住，约束不是用来限制你的，而是用来保护你的。你越早学会使用它，后面的坑就越少。
