如何在MySQL中实现外键约束？外键的创建与管理完整教程！

嘿，我们来谈谈MySQL中的外键约束。
这个东西在数据库设计中非常重要。
这就像是给数据穿上了“紧身衣”，防止其乱跑，保证数据的完整性。

首先我们来谈谈如何创建外键约束。
最推荐的方法是在创建表时直接定义。
例如，我已经有一个项目。
创建父表和子表时我使用了这种方法：
sql 创建表父表（ id INT 主键自动递增， 名称 VARCHAR(1 00) );
创建表child_table ( id INT 主键自动递增， 父 ID INT， 描述 VARCHAR(2 5 5 ), 约束 fk_parent_id 外键 (parent_id) 引用parent_table(id) 在级联上删除，在级联上更新 );
这里CONSTRAINT fk_parent_id是自定义的外键名称，方便以后管理。
FOREIGN KEY (parent_id) 表示子表的外键列，REFERENCES Parent_table(id) 表示父表的主键列。
ON DELETE CASCADE ON UPDATE CASCADE 定义了级联操作，即当父表中的记录被删除时，子表中相应的记录也被删除。

一旦表已创建并且您想要添加外键约束，您可以使用 ALTER TABLE 语句，如下所示：
sql 更改表子表 添加约束 fk_parent_id 外键 (parent_id) 引用parent_table(id) 删除级联时更新级联；
外键约束管理主要涉及查看和删除。
查看表结构，外键定义出现在 SHOW CREATE TABLE 的输出中。
要删除外键，只需使用 ALTER TABLE DROP FOREIGN KEY 即可。

说到优化，外键约束会对性能产生一些影响，尤其是对于写入。
您可以通过确保索引覆盖范围并选择适当的级联行为来实现优化。
例如，您可以手动在父表的引用列（非主键）上添加索引。

常见错误，如：如数据类型不匹配、引用的列没有索引、存储引擎不支持等。
如果遇到这些问题，可以查看错误信息、检查数据类型和属性、检查索引是否存在、确认存储引擎、检查数据一致性、检查表/列拼写。

一般来说，外键约束是保证数据完整性的好帮手。
尽管性能开销可能很小，但其价值远远超过这些损失。
正确的设计可以最大限度地减少性能下降，同时确保数据完整性。

如何在MySQL中清理错误的约束条件？通过ALTER TABLE DROP CONSTRAINT修复

嘿，让我告诉你重建数据库的陷阱。
非常实用。
听着，当时我是上海的客户。
他们的系统正在运行，突然报告了一个错误，说这是一个瓶颈问题。
我看不清具体是什么，但这位顾客非常担心，他跳了起来。
当我看到这个的时候，我想，是的，必须放在第一位，否则就会被随机删除。

我运行了 SHOW CREATE TABLE rows；在他的仆人中。
当我看到这一点时，哦，原来有一个名为 fk_customer_id 的外键约束，它连接了行表和客户表。
我只是对客户说，别急躁，说话前要小心。

然后我运行了另一个 SELECT CONSTRAINT_NAME, CONSTRAINT_TYPE FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS WHERE TABLE_SCHEMA='mydatabase' AND TABLE_NAME='commands';。
这次信息完整并且确实是外键。
现在我相信了。

在采取行动之前，我告诉客户先备份数据。
我是一个害羞的人，我总是害怕搞砸。
他们同意了，我备份了订单表和客户表中的所有数据。
备份完成后，我在测试环境中再次测试，删除了外键，看看是否还有其他问题。
幸运的是，毫无疑问。

在生产环境中我小心翼翼地执行了 ALTER TABLE ORDER BY REQUEST CONTAINING fk_customer_id ;。
删除后，我又问了几个问题，以确认外键确实消失了。
客户也测试了一下，说系统没问题。

后来还有一次，在杭州，有一个方案，客户非要我用特殊手段删除，说没用。
我在想，我得小心一点，如果删除数据和重复项怎么办。
我迈出第一步。
找到独特的需求 idx_unique_email。
然后我在测试环境中删除，发现删除后可以正常添加数据，没有崩溃。

生产环境中，我还是先返回。
删除了，我要求客户先不要输入数据。
如果重复的话，我会要求他们先清理它。
幸运的是，非常干净的客户数据不存在任何问题。

这里删除约束的时候要小心。
备份数据，测试，确认，一步一步，不要手抖。
当时我有一个同事删除了主键。
因此，数据被放在整个表中。
这是一场悲剧。
所以，做这项工作的时候一定要稳。

MySQL中constraint的详解

嘿，让我告诉你一件事。
当我刚开始从事数据库工作时，我真的不了解MySQL的限制，并且遇到了很多陷阱。
给大家讲一个我遇到的真实场景。

前年，我在一个电商项目中做数据库设计。
那个项目中数据量不大，只有几百张表。
一开始我想省事，就用一个自增ID作为用户表的主键。
但后来业务需要添加用户创建时间作为唯一标识。
我想换主键，但是一晚上都想不通。
最后只好加上唯一索引凑合了。
这个教训真是惨痛。
所以，一旦选择了主键，以后就不要考虑更改它。

还有一次，当我用外键连接订单表时，我没有添加外键约束。
结果有人把订单中的商品ID改成了不存在的值，整个系统就崩溃了。
后来，我很快为所有表添加了外键约束，特别是与产品和客户表相关时。
我不得不多次检查ON DELETE CASCADE部分，生怕如果产品被删除，订单表也会随之被删除，损失巨大。

去年，在另一家公司，我向表中添加了对邮箱的唯一约束。
结果业务说同一个邮箱允许注册两次，所以忘记加NOT NULL，导致插入空值时没有报错。
后来查资料的时候，发现一堆空邮箱，真是哭笑不得。

我们来谈谈检查约束。
我有一个表是库存表，数量不能为负数。
我使用 CHECK 约束编写了一个条件。
结果MySQL 5 .7 还不支持，只能用触发器来实现。
这让我头大了。

关于默认约束，我没有犯任何错误。
它的意思是NOT NULL，这很容易被忘记。
我设计表的时候，以为用户名可能为空，但是忘记加默认值了。
结果插入数据的时候还得手动填写，很麻烦。

我经常使用自动增量约束，尤其是在制作日志表时。
每次插入都会自动添加一个ID，省去了很多麻烦。
不过要注意，如果自增ID用完了，就得手动调整，这是相当烦人的。

约束命名方面，刚开始是随便用缩写，但是几个月后想换表的时候，发现约束名称全乱了，分不清哪个是哪个，只好全部删除，重新添加。
现在我给约束命名具有业务含义，例如fk_customer。
我一眼就能看出它们是外键约束。

一般来说，如果约束运用得好，可以省去很多麻烦。
但如果你用得不好，还是会让人头疼。
所以，设计桌子的时候，不要只想着省事。
添加适当的约束，以便您将来可以省心。