数据库约束那些事儿，怎么设置才不会出错又能保证数据安全

开始）

说到数据库，你可以把它想象成一个超级大的、有严格规矩的仓库，里面放着你公司所有重要的数据，比如用户信息、订单记录、账户余额等等，这个仓库可不能谁想进就进，东西想怎么放就怎么放，不然就全乱套了，今天咱们聊的“数据库约束”，就是给这个仓库定下的“铁规矩”，这些规矩的目的，就是保证仓库里的数据整整齐齐、准确无误,而且安全可靠。

怎么定这些规矩才能既不出错，又能把数据保护好呢？这事儿得一步步来,不能瞎设。

第一道防线：保证每件货物都有唯一身份证——主键约束。

想象一下，仓库里堆满了箱子，如果每个箱子都没有一个唯一的编号，你怎么快速找到其中一个？肯定会找得头晕眼花，主键就是这个“唯一编号”，它要求一张数据表里的每一行数据,都必须有一个独一无二的标识。

怎么设才不会错？

1. 选对字段：最好用一个和业务没啥关系的、纯粹的数字ID来当主键（比如自增ID），别用用户的手机号或者身份证号，虽然它们也是唯一的，但万一用户换了手机号或者身份证号需要更新，你就会遇到大麻烦，因为主键通常是禁止修改的，这叫“业务无关性”，是很多资深工程师在实践中总结的经验（参考自《阿里巴巴Java开发手册》）。
2. 确保唯一：系统会自动帮你检查，如果你插入了两条相同ID的数据，它会直接报错，拒绝入库,这就从根儿上避免了重复数据的产生。

第二道防线：保证货物信息不残缺——非空约束。

有些信息是绝对不能空的，比如用户的密码、订单的金额，你要是允许这些字段为空，那可能就会出现一个没有密码的账户，或者一个金额为空的订单,这显然是错误的。

怎么设才不会错？

• 关键信息必须设：在设计表的时候，就要想清楚，哪些字段是这条记录的“灵魂”，缺了它记录就没意义了，把这些字段统统设为“非空”，这会强制程序员在存数据时必须填上这个值,否则数据库就不让存。
• 避免过度使用：但也不是所有字段都得非空，比如用户的“昵称”字段，如果允许用户不设置，那就可以为空，过度使用非空约束,会让程序变得不灵活。

第三道防线：保证货物能对得上号——外键约束。

这是保证数据之间“关系”正确的最重要规矩，你有一张“订单表”，里面记录了哪个用户买了什么东西，这个“哪个用户”就必须在“用户表”里真实存在,你不能凭空编造一个用户ID塞到订单里。

怎么设才不会错？

• 明确表之间的关系：外键就是用来链接两张表的，设置了外键约束后，数据库会做两件事：
  • 禁止乱认亲戚：当你往“订单表”插入一条新订单时，它指定的用户ID必须在“用户表”里存在,否则插入失败。
  • 防止随意抛弃：当你想从“用户表”里删除一个用户时，数据库会先去“订单表”里查一下有没有这个用户的订单，如果有，它就会阻止你删除，除非你先处理掉那些订单，这叫“引用完整性”，能有效防止数据变成没人要的“孤儿数据”。
• 注意性能影响：外键约束虽然好，但它会增加数据库的检查开销，在大规模并发写的场景下可能会影响性能，所以有些大型互联网公司会在程序代码层面去保证这种关系，而不用数据库的外键，但对于绝大多数应用来说，使用外键是更简单、更可靠的选择。

第四道防线：保证货物符合规格——唯一约束和检查约束。

• 唯一约束：它和主键有点像，也要求唯一，但一张表只能有一个主键，却可以有多个唯一约束，比如用户的邮箱、手机号，这些字段虽然不是主键，但你也希望它们是唯一的，不能重复注册,这就用唯一约束来保证。
• 检查约束：这个规矩更细致，它可以规定某个字段的值必须满足什么条件。“年龄”字段必须大于0；“性别”字段只能是“男”或“女”；“订单状态”只能是你预先定义好的那几个值。

怎么设才不会错？

• 善用唯一约束处理业务唯一性：把那些业务上不允许重复的字段（除主键外）加上唯一约束,能避免很多脏数据。
• 检查约束是数据质量的守门员：尽可能地把你能想到的业务规则通过检查约束来实现，确保金额不能为负数，把校验逻辑放在数据库这一层，比写在程序里更让人放心，因为能防止任何程序（哪怕是有Bug的程序）写入非法数据,这是一种重要的防御性设计思想。

第五道防线：给数据上把安全锁——权限控制。

前面说的都是保证数据“对不对”的规矩，但数据“安不安全”是另一个维度的问题，这就涉及到权限控制了,你不能让仓库的保洁阿姨也有权限查看公司的财务报表吧？

• 最小权限原则：这是信息安全领域的黄金法则（在众多安全标准如ISO27001中均有体现），意思是,给每个操作数据库的程序或账号只授予它完成工作所必需的最小的权限。
• 具体做法：
  • 读写分离：专门处理用户查询的程序，只给它“读”的权限，绝对不能给“写”或“删”的权限，这样即使这个程序被黑客攻击了，他也只能看数据,不能搞破坏。
  • 分表授权：管理订单的程序没必要有权限去操作用户的密码表。
  • 避免使用超级管理员账号：很多项目图省事，直接用数据库的root或sa这种超级管理员账号连接数据库，这是非常危险的，一旦这个账号泄露，整个数据库就裸奔了，一定要为不同的应用创建专属的、权限被严格限制的账号。

定好数据库的规矩，是一个系统工程，你需要像设计仓库的管理条例一样，从“每个物品的唯一标识”（主键），到“关键信息不缺项”（非空），到“物品之间的正确关联”（外键），再到“物品本身的规格达标”（检查约束），一层层地把关，还要严格限制谁能进仓库，进去了能干什么（权限控制）。

把这些规矩在项目一开始就设计好，并且严格执行，虽然前期会多花一点时间，但它能为你后期避免数不清的bug、数据混乱和安全漏洞，让数据库这个“铁面无私的管家”来帮你守规矩，远比依赖程序员的自觉和代码的完美更靠谱。 结束）