MySQL — 关联

说白了，外键就是B表用来指向B表中某条记录的“身份证号”。
这个问题复杂化有几点：首先，最重要的是外键可以验证B表指定的信息是否确实存在于A表中。
去年我们跑的项目就因为这个失败了。
不包含外键的 3 ,000 级数据输入失败。
还有一点是，创建外键时，必须指定ON DELETE和ON UPDATE策略，例如ON DELETE。
CASCADE（当它删除表 A 中的记录时，它也会删除对表 B 的引用）。
很多人都不关注这件事，说实话，很混乱。
还有一个重要的细节。
MySQL 将使外键约束名称本身无效，但您可以使用 ALTER TABLE 更改名称。
例如，test_mysql.importdetails 的外键称为 fk_member_id。
这个一定要写，不然删除块的时候很容易溜。

一开始我以为外键只需要定义就可以了，后来发现我错了。
外键索引不会自动创建。
表B的外键字段必须单独建立索引，否则查询的效率会急剧下降。
等等，还有一件事。
内连接和外连接之间的区别不仅仅是数据的大小。
内部整合是一条“双向路”，双方都必须满足条件；外在的依恋是“单相思”。
例如，左坐标表示左表拥有所有内容而右表缺失。

建议使用 ON DELETE SET NULL 来处理删除条件。
它比 CASCADE 更安全。
至少对表B的引用不会消失。
外连接工作速度很慢，所以要小心不要在百万级表上做左连接。

深入理解MySQL中的UPDATE JOIN语句

嘿嘿，你说的JOIN UPDATE其实还是蛮实用的，但是我还是要给你说一下我上次遇到的坑。

上一次做电商公司的数据库优化是在2 02 3 年夏天，当时用户表和业务表经常一起使用。
他们当时有一个需要。
他们已经拥有业务创建者的 ID，但他们想要添加一个字段来存储创建者的姓名。
单纯依靠ID来查找历史数据中的名字，经过长时间的查找很容易出现错误。

当时的技术总监让我尝试使用UPDATE JOIN。
我写的SQL是这样的：
sql 更新bus_history b INNER JOIN 用户 u ON b.creator_id = u.id SET b.creator_name = u.name 其中 u.id 不为空；
你猜怎么着？运行了几分钟，几十万条数据就被改变了，一些不相关的记录也几乎被改变了。
后来才知道是连接条件写得太简单了，WHERE子句也很混乱，根本没有仔细检查。

你说得对，这个功能确实很棒，但是使用的时候确实需要注意一下。
特别是对于连接条件和 WHERE 子句，一个错误就可能导致灾难。
上次业务创建者的问题是因为我没有添加 IS NOT NULL 的 u.id。
结果，所有的空值都被改变了。
需要很长时间才能恢复。

无论如何，当你使用它时，你应该先在测试环境中运行它。
较小的数据量就可以了。
如果像上次那样有几十万条数据的话，万一出了问题就很麻烦了。