Mysql

关注公众号 jb51net

关闭
首页 > 数据库 > Mysql > mysql sql_mode

mysql修改sql_mode报错的解决

作者:守护者ly

今天在Navicat中运行sql语句创建数据表出现了错误Err 1067。本文主要介绍了mysql修改sql_mode报错的解决,感兴趣的可以了解一下

一 ERR 1067引发的血案

       今天在Navicat中运行sql语句创建数据表出现了错误Err 1067。而这条语句在有些同事的mysql上是正确的,但是在有些人那里就报错。你说气不气人。

原因竟然是timestamp的默认值不正确。

查阅资料得知,mysql5.7版本中有了一个STRICT mode(严格模式),而在此模式下默认是不允许设置日期的值为全0值的,所以想要

解决这个问题,就需要修改sql_mode的值。

二 问题的源头sql_mode

       我们可以进入到mysql中一探sql_mode的究竟。首先进入到mysql的安装目录下的bin目录,使用管理员用户登录mysql数据库。

使用命令 mysql –h localhost –u root–p  其中-h是指定主机名或IP地址, -u是指定用户, -p是使用密码登录。

使用命令 select @@sql_mode; 可以查看sql_mode的值。如果输入了命令却没有反应,只是单单出现了 -> ,那么我想

你多半是应该像我一样,没有输入“;”。

通过上图中的结果我们可以看到sql_mode中有NO_ZERO_IN_DATE和NO_ZERO_DATE,在命令行中输入

set sql_mode=(select replace(@@sql_mode,'NO_ZERO_IN_DATE,NO_ZERO_DATE','')); 可以修改sql_mode。

之后可以查看一下sql_mode的值。可以发现已经成功去掉了NO_ZERO_IN_DATE和NO_ZERO_DATE。

重新运行了一下建表的sql语句,发现没什么卵用,依然Err 1067。不要想什么姿势不对的问题了,只是全局的sql_mode没有设置而已,而这里设置的sql_mode对大局根本没有影响。

       使用命令select @@global.sql_mode; 可以查看全局sql_mode的值。

剩下的操作与之前的sql_mode设置是同理可证的,只是将之前sql_mode的地方都换成了@@global.sql_mode,如图。

完成设置之后可以在Navicat中重新运行一下sql语句了,不过在那之前要先重新连接数据库,不然依然Rrr 1067。

别问我为什么,叫我雷锋就好。运行结果如下:

好了,这次表是创建成功了的,而且换了一个错误Err 1055,翻译过来就是“无法给包含一个非聚合的列information_schema.

PROFILING.SEQ进行分组,这个功能不再依赖分组,且与新的规则不兼容sql_mode=only_full_group_by”。也说了这是由于

sql_mode中的“ONLY_FULL_GROUP_BY”导致的。可以再次修改sql_mode。

删除之前创建好的表,重新连接数据库,运行sql语句,然后就棒棒棒了。

当然这种解决方法只是扬汤止沸,一旦重启mysql数据库,之前费了狼劲设置的一堆值一夜回到解放前。

       这也是有解决办法的,下面会给大家介绍。

三 设置sql_mode

       可以通过修改配置文件的方式设置sql_mode,这样在数据库重启之后sql_mode的值也不会改变。

       首先我们需要知道的是mysql的配置文件的加载顺序。进入到数据库安装目录的bin目录下,使用命令

mysqld --verbose –help可以看到,不过这个命令的输出结果太长了,我暂时没有找到更合适的命令来查看。

加载顺序如图:

这些配置文件在加载时,后加载的会将之前加载的配置文件中的相同的值覆盖。不过我只在mysql的安装目录下找到了

一个名字很像的配置文件,其余的都没有找到。

将这个文件备份好之后,修改名称为my.ini,与给出的加载配置文件顺序中的文件对应。然后打开文件,我这里的配置

文件中的sql_mode只有两个值。

重启数据库后,使用命令查看sql_mode的值,发现与配置文件中完全吻合,搞定!

附加几种常见的sql_mode值的介绍:

几种常见的mode介绍

到此这篇关于mysql修改sql_mode报错的解决 的文章就介绍到这了,更多相关mysql sql_mode内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

您可能感兴趣的文章:
阅读全文