一、问题由来
该问题的发现是从测试环境向生产环境导数据时产生的,执行导入就报Cannot add foreign key constraint外键的错,刚开始以为是数据的问题,但是反复查看并没有发现有什么问题,陷入了僵局。
二、问题解决方法
经过各种查资料,了解到了其实就是因为外键检查导致的错误,于是就想到了我们可以临时关闭外键检查,这样等我们完成数据的导入,再进行开启那么就可以了。说干就干,查询mysql的官方手册,我们进行了尝试:
2.1 尝试一
我们大部分人在该步骤就可以解决问题,但是有时我们需要用尝试二的方法去解决,究其根本原因,我认为就是全局和局部的问题
select @@FOREIGN_KEY_CHECKS
结果如下,我们可以看到默认为1,代表检查外键,这就是我们导入数据报错的原因所在:
那么我们就可以将其置为0,即不检查外键这样就可以解决问题。命令如下:
SET @@FOREIGN_KEY_CHECKS=0;
很多时候截至到该步骤我们重新导入就会发现问题已经解决了,记得完成导入数据之后或者其他操作之后记得将值重新置为1。
SET @@FOREIGN_KEY_CHECKS=1;
但是有时候会发现问题没有被解决,我们接着看步骤二。
2.2 尝试二
在第一步的基础我们加上@@GLOBAL,即设置为全局变量,我的问题也就是在尝试二解决的。我们仍然先看一下默认值:
select @@global.FOREIGN_KEY_CHECKS
查询结果为:
然后我们将其设置为0:
SET @@global.FOREIGN_KEY_CHECKS=0;
然后我们执行select语句,确认已经修改成0了,我们开始导入数据或者其他的操作,我们会发现已经成功了,执行完我们的业务之后,我们记得将值修改会原来的值。
SET @@global.FOREIGN_KEY_CHECKS=1;
三、拓展-修改变量副作用
该部分内容是对上边内容的一个拓展,是想分享一个理念,我们并不是为了解决问题而解决问题,我们需要有更深层次的思考,虽然变量被修改后我们的问题解决了,但是并不是所有的变量都适合去修改的,我们在实践的过程中一定要分清楚,我们就举一个具体的例子来说明。
- query-cache-size
该值在MySQL启动的时候是一次性分配并初始化好的,如果我们在运行时修改该值(即使是修改成一样的值),mysql也会立刻马上删除所有缓存的查询并重新分配到指定大小,并重新初始化内存。因为数据库是逐个清除缓存的,不是一下子全部干掉,所以这个过程可能需要花费较长的时间,而且在完成之前服务器都无法对外服务。
这样我们推理一下就会发现其中的利害关系,所以我们在设置变量的时候一定要慎之又慎,别一不小心干出被离职的事情。
四、结语
道阻且长,行则将至,行而不辍,未来可期,加油。
如果文章解决了你的问题,对你的进步有那么一点帮助,那么就给点个赞支持一下,如果觉得文章非常对你的胃口,那么欢迎你关注我,这里有资源,有内推,有和你志同道合的朋友,咱们一起打怪升级。