Cannot add foreign key constraint全网唯一全面正解

一、问题由来

该问题的发现是从测试环境向生产环境导数据时产生的，执行导入就报Cannot add foreign key constraint外键的错，刚开始以为是数据的问题，但是反复查看并没有发现有什么问题，陷入了僵局。

二、问题解决方法

经过各种查资料，了解到了其实就是因为外键检查导致的错误，于是就想到了我们可以临时关闭外键检查，这样等我们完成数据的导入，再进行开启那么就可以了。说干就干，查询mysql的官方手册，我们进行了尝试：

2.1 尝试一

我们大部分人在该步骤就可以解决问题，但是有时我们需要用尝试二的方法去解决，究其根本原因，我认为就是全局和局部的问题

select @@FOREIGN_KEY_CHECKS
1

结果如下，我们可以看到默认为1，代表检查外键，这就是我们导入数据报错的原因所在：

那么我们就可以将其置为0，即不检查外键这样就可以解决问题。命令如下：

SET @@FOREIGN_KEY_CHECKS=0;
1

很多时候截至到该步骤我们重新导入就会发现问题已经解决了，记得完成导入数据之后或者其他操作之后记得将值重新置为1。

SET @@FOREIGN_KEY_CHECKS=1;
1

但是有时候会发现问题没有被解决，我们接着看步骤二。

2.2 尝试二

在第一步的基础我们加上@@GLOBAL，即设置为全局变量，我的问题也就是在尝试二解决的。我们仍然先看一下默认值：

select @@global.FOREIGN_KEY_CHECKS
1

查询结果为：

然后我们将其设置为0：

SET @@global.FOREIGN_KEY_CHECKS=0;
1

然后我们执行select语句，确认已经修改成0了，我们开始导入数据或者其他的操作，我们会发现已经成功了，执行完我们的业务之后，我们记得将值修改会原来的值。

SET @@global.FOREIGN_KEY_CHECKS=1;
1

三、拓展-修改变量副作用

该部分内容是对上边内容的一个拓展，是想分享一个理念，我们并不是为了解决问题而解决问题，我们需要有更深层次的思考，虽然变量被修改后我们的问题解决了，但是并不是所有的变量都适合去修改的，我们在实践的过程中一定要分清楚，我们就举一个具体的例子来说明。

 - query-cache-size
1

该值在MySQL启动的时候是一次性分配并初始化好的，如果我们在运行时修改该值（即使是修改成一样的值），mysql也会立刻马上删除所有缓存的查询并重新分配到指定大小，并重新初始化内存。因为数据库是逐个清除缓存的，不是一下子全部干掉，所以这个过程可能需要花费较长的时间，而且在完成之前服务器都无法对外服务。

这样我们推理一下就会发现其中的利害关系，所以我们在设置变量的时候一定要慎之又慎，别一不小心干出被离职的事情。

四、结语

道阻且长，行则将至，行而不辍，未来可期，加油。

如果文章解决了你的问题，对你的进步有那么一点帮助，那么就给点个赞支持一下，如果觉得文章非常对你的胃口，那么欢迎你关注我，这里有资源，有内推，有和你志同道合的朋友，咱们一起打怪升级。