菜鸟学数据库（四）——超键、候选键、主键、外键

那天我在整理朋友们的旧照片，找到毕业照，发现居然有两个人的学号是一样的。
当时我就想，这个学生证是不是可以作为我学生证的唯一标识呢？后来想想，实在不能这么想。

超级开关看起来像图片中的功能。
如果你看某人的脸，你可以通过左眼的长度和颜色来识别他们。
这类似于超级键，例如（学号，姓名）。
但如果你只有学号，万一严重了怎么办？所以超级密钥是可以唯一识别一个人的所有特征的组合。

候选开关很智能，它选择最精简的功能。
例如，ID 号是唯一的。
即使删除任何号码，您也可以通过身份证号码完全识别一个人。
有时学号也可以作为候选键，但这取决于学校是否严格控制。

主键是特定的“杰作”。
老师在墙上展示的图片并不是随机选择的。
同样在数据库中，主键是系统识别的唯一参与者。
我们学校选择学号作为主键。
其实身份证号是最全的，但是学号适合系里的公告。
记得2 005 年系统升级时，由于主键重复、数据删除错误，系里几乎所有学生的名字都变成了王五。

外键是图像后面的注释。
学生的图片上写着“老师：李老师”，而这个李老师是另一个群里的名字。
教师编号位于数据库中的学生表中，是指教师表的主键。
这就是外键的作用。
2 01 2 年，我帮教务处查抄袭，发现很多学生的外键指向空白老师。
最后我发现导入数据的时候忘记更新特征表了。

超级键、候选键、主键、外键，说白了就是信息的分类是如何分类的。
就像整理照片一样，有的按时间，有的按人物，有的按事件。
但是等等，还有别的事情。
我突然想到图书馆的借书系统是用书号作为主键的。
原来有些旧书的书号是重叠的，最后条码解决问题。
这意味着什么？如果主键选得不好，整个系统都会受到影响。

SQL外键约束如何添加 外键约束添加的4个步骤

说实话，当我第一次遇到SQL外键约束时，我完全被那些令人困惑的术语搞糊涂了。
但后来慢慢开始，发现只要学会几个关键点，其实就变得相当好用了。

首先让我告诉你我掉进陷阱的一件事。
我曾经在电子商务系统中添加了外键约束。
订单表中的 user_id 应该链接到用户表中的 id。
结果我手一抖，把字段名写反了——子表用user_id做外键，父表用id做主键。
这直接导致系统在插入数据时报错。
我担心得满头大汗，所以我最终删除并重写了限制。
因此，在定义表关系阶段，需要反复检查，避免出现此类低级错误。

有趣的是，外键约束配置选项实际上隐藏了很多技巧。
比如ONUPDATECASCADE，上次我在连锁店系统中使用它时，老板称赞它省去了麻烦——当他调整一个产品编号时，所有依赖于该编号的订单都会自动更新，并且所有数据更改都可以通过一行SQL完成。
但如果你不明白这一点，突然发现某个子表没有同步更新，那么查找错误的时间就够写好几篇文章了。

说到级联删除，这绝对是外键约束中最小心的地方。
我曾经帮朋友调试过一个论坛系统。
设置ONDELETECASCADE后，他不小心删除了管理员帐户。
结果，整批帖子被“物理删除”。
幸亏他及时备份了数据，不然损失可就……啧啧。
所以现在我在写外键约束的时候，总是会额外加上注释来提醒后人：“注意：使用级联删除与
我也踩过循环依赖的坑，记得有一个ERP项目，供应商表和产品表死循环在一起，当时真的很头疼，如果你改变一张表的结构，另一张表的外键就会出问题，最后我不得不重新设计，把“供应关系表”从中间拆下来，就彻底解决了。
如果你没有经验在这个领域，确实建议在开始工作之前先画一个ER图并明确依赖关系。

回顾这些操作，外键约束实际上就像数据库中的“交通警察”，这会减慢更新的插入速度，但代价是数据一致性，我有一个在测试环境中使用MySQL的插入表的速度实际上快了两到三倍，但后来在生产中，我发现由于数据混乱而导致的业务逻辑失败的数量。
因此，性能和可靠性之间的平衡取决于具体的业务场景。