MySQL5.7中的sql_mode默认值带来的坑及解决方法

在正常项目开发过程中,如果MySQL版本从5.6升级到5.7版本。作为DBA在考虑数据库版本升级带来的影响时,一般会有几个注意点:

sql_mode
optimizer_switch

本文主要内容是MySQL升级到5.7版本之后,由于默认的 sql_mode 值带来的坑以及对应的解决方案。

案例一:ONLY_FULL_GROUP_BY

问题描述

MySQL版本从5.6升级至5.7之后,部分SQL执行报错,报错信息如下:

ERROR 1055 (42000): Expression #3 of XXXXXX list is not in GROUP BY clause and contains nonaggregated column ‘XXXXX.XXXXXX' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

这个问题原因在于从5.6升级至5.7版本后 sql_mode 默认值发生了改变,在5.7版本的 sql_mode 默认值中有意向 ONLY_FULL_GROUP_BY ,该选项的含义表示:对于使用 GROUP BY 进行查询的SQL,不允许 SELECT 部分出现 GROUP BY 中未出现的字段,也就是 SELECT 查询的字段必须是 GROUP BY 中出现的或者使用聚合函数的。

解决方案

方案一(不推荐):修改5.7版本 sql_mode 值,将 ONLY_FULL_GROUP_BY 去掉

ONLY_FULL_GROUP_BY 是加强SQL规范的,其目的是让SQL查询出来的结果更符合规范,更准确。

如果没有 ONLY_FULL_GROUP_BY 规范限制,那么则能允许以下SQL的执行: SELECT a,b,c FROM t GROUP BY a 。SQL按照a字段值进行分组,当同一个a字段值对应多个b或者c值时,查询结果中的b,c值是不确定的。

方案二:改写SQL

案例二:NO_ZERO_DATE & NO_ZERO_IN_DATE & time_zone

问题描述

排错阶段一

MySQL版本从5.6升级至5.7之后,创建表的过程中失败:

mysql> CREATE TABLE `t_manager` (
  .....
  ->  `CREATE_DATETIME` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  ->  `MODIFIER` varchar(32) DEFAULT NULL COMMENT '更新人',
  ->  `MODIFY_DATETIME` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
  ->  `IS_DELETED` bit(1) DEFAULT b'0' COMMENT '删除状态 1:删除 0:未删除',
  ->  `IS_ENABLE` bit(1) DEFAULT b'1' COMMENT '启用状态 1:启用 0:禁用',
  ->  PRIMARY KEY (`CACHE_ID`)
  -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
ERROR 1067 (42000): Invalid default value for 'MODIFY_DATETIME'

错误提示 MODIFY_DATETIME 字段设置的默认值是无效的,考虑到刚从5.6版本升级到5.7版本,于是又去翻了翻5.7中默认的 sql_mode 值。结果发现了两个可能存在影响的选项:

NO_ZERO_DATE
NO_ZERO_IN_DATE

排错阶段二

于是解决方案就是按照 NO_ZERO_DATE 以及 NO_ZERO_IN_DATE 的要求设置默认值,将 MODIFY_DATETIME 字段默认值设置为'1001-01-01 01:01:01',结果发现还是无法成功创建表:

mysql>CREATE TABLE `t_manager` (
  .....
  ->  `CREATE_DATETIME` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  ->  `MODIFIER` varchar(32) DEFAULT NULL COMMENT '更新人',
  ->  `MODIFY_DATETIME` timestamp NOT NULL DEFAULT '1001-01-01 01:01:01' ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
  ->  `IS_DELETED` bit(1) DEFAULT b'0' COMMENT '删除状态 1:删除 0:未删除',
  ->  `IS_ENABLE` bit(1) DEFAULT b'1' COMMENT '启用状态 1:启用 0:禁用',
  ->  PRIMARY KEY (`CACHE_ID`)
  -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
ERROR 1067 (42000): Invalid default value for 'MODIFY_DATETIME'

查看了所有的 sql_mode 值,都符合规范,但是表还是创建不成功。只好去官方手册上找找timestamp介绍:

The TIMESTAMP data type is used for values that contain both date and time parts. TIMESTAMP has a range of ‘1970-01-01 00:00:01' UTC to ‘2038-01-19 03:14:07' UTC.

排错阶段三

可以看到官方定义中timestamp字段值的范围是'1970-01-01 00:00:01'到'2038-01-19 03:14:07',原来是我们设置的默认值不在timestamp范围之内。于是再次修改默认值:

mysql>CREATE TABLE `t_manager` (
  .....
  ->  `CREATE_DATETIME` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  ->  `MODIFIER` varchar(32) DEFAULT NULL COMMENT '更新人',
  ->  `MODIFY_DATETIME` timestamp NOT NULL DEFAULT '1970-01-01 00:00:01' ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
  ->  `IS_DELETED` bit(1) DEFAULT b'0' COMMENT '删除状态 1:删除 0:未删除',
  ->  `IS_ENABLE` bit(1) DEFAULT b'1' COMMENT '启用状态 1:启用 0:禁用',
  ->  PRIMARY KEY (`CACHE_ID`)
  -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
ERROR 1067 (42000): Invalid default value for 'MODIFY_DATETIME'

邪了门,居然还是无法成功创建表。实在是没辙了,向同事求救,同事说他在机器上试试,结果同样的语句在他的MySQL上执行成功,同样是5.7.23版本。

百思不得其解。

一气之下将两边的参数值拿出来对比了一下,果然找到了不同的根本。

测试环境 同事环境
system_time_zone=CST system_time_zone UTC
time_zone='+08:00' time_zone=SYSTEM

回过头来看timestamp字段定义的范围:

The TIMESTAMP data type is used for values that contain both date and time parts. TIMESTAMP has a range of ‘1970-01-01 00:00:01' UTC to ‘2038-01-19 03:14:07' UTC.

这个时间范围指的是UTC时区的时间范围,测试环境设置了CST东八区的时区,则对应的时间范围上也需要对应的加8小时。所以将timestamp字段默认值修改为'1970-01-01 08:00:01',表终于创建成功。

mysql>CREATE TABLE `mn_cache_refresh_manager` (
  ......
  ->  `CREATE_DATETIME` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  ->  `MODIFIER` varchar(32) DEFAULT NULL COMMENT '更新人',
  ->  `MODIFY_DATETIME` timestamp NOT NULL DEFAULT '1970-01-01 08:00:01' ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
  ->  `IS_DELETED` bit(1) DEFAULT b'0' COMMENT '删除状态 1:删除 0:未删除',
  ->  `IS_ENABLE` bit(1) DEFAULT b'1' COMMENT '启用状态 1:启用 0:禁用',
  ->  PRIMARY KEY (`CACHE_ID`)
  -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.02 sec)

总结

以上所述是小编给大家介绍的MySQL5.7中的sql_mode默认值带来的坑及解决方法,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对我们网站的支持!

(0)

相关推荐

  • MySql版本问题sql_mode=only_full_group_by的完美解决方案

    1.查看sql_mode select @@sql_mode 查询出来的值为: ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION 2.去掉ONLY_FULL_GROUP_BY,重新设置值. set @@sql_mode ='STRICT_TRANS_TABLES,NO_ZE

  • mysql sql_mode="" 的作用说明

    sql_mode="",即强制不设定MySql模式(如不作输入检测.错误提示.语法模式检查等)应该能提高性能,但有如下问题: 如果插入了不合适数据(错误类型或超常),mysql会将数据设为"最好的可能数据"而不报错,如: /数字 设为:0/可能最小值/可能最大值 /字符串 设为:空串/能够存储的最大容量字符串 /表达式 设为:返回一个可用值(1/0-null) 所以,解决办法是:所有列都要采用默认值,这对性能也好. mysql_mode的详细描述: 在mysql 5

  • 解决MySQL 5.7.9版本sql_mode=only_full_group_by问题

    MySQL 5.7.9版本sql_mode=only_full_group_by问题 用到GROUP BY 语句查询时com.MySQL.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'col_user_6.a.START_TIME' which is not func

  • Mysql之SQL Mode用法详解

    一.Mysql SQL Mode简介 通常来说MySQL服务器能够工作在不同的SQL模式下,并能针对不同的客户端以不同的方式应用这些模式.这样,应用程序就能对服务器操作进行量身定制以满足自己的需求.这类模式定义了MySQL应支持的SQL语法,以及应该在数据上执行何种确认检查.这样,就能在众多不同的环境下.与其他数据库服务器一起更容易地使用MySQL.可以使用"--sql-mode="modes""选项,通过启动mysqld来设置默认的SQL模式.而从MySQL 4.

  • MySQL5.7中的sql_mode默认值带来的坑及解决方法

    在正常项目开发过程中,如果MySQL版本从5.6升级到5.7版本.作为DBA在考虑数据库版本升级带来的影响时,一般会有几个注意点: sql_mode optimizer_switch 本文主要内容是MySQL升级到5.7版本之后,由于默认的 sql_mode 值带来的坑以及对应的解决方案. 案例一:ONLY_FULL_GROUP_BY 问题描述 MySQL版本从5.6升级至5.7之后,部分SQL执行报错,报错信息如下: ERROR 1055 (42000): Expression #3 of X

  • CentOS 7中升级MySQL 5.7.23的坑与解决方法

    前言 最近发现CentOS 7下升级MySQL5.7.23的一个坑,以前面升级到MySQL 5.7.23的一个集群为例 在我们环境下打开文件描述符个数的参数open_files_limit在MySQL 5.6.21下都统一配置为65535,而CentOS 7系统下安装MySQL5.7.23的open_files_limit参数的默认值为5000 否则像分区表数量较多的集群,打开的文件个数过大时,数据库就会报错. 原因如下: 1.CentOS 7安装MySQL5.7.23,服务管理发生了变化,从s

  • 浅谈vue中$event理解和框架中在包含默认值外传参

    在vue中普通方法中默认带有event DOM事件如greet方法,如果是内联函数的话如warn方法,只需要在定义方法的地方同时传入$event即可,这里需要强调的是在iview中,这里用的是select组件,在其on-change事件中如果想要传入自定义的参数,使用直接传参的方式,获取的是传入的参数,那么如何获取到该方法默认的返回值(即不传参数时返回的默认选中值),这里使用 $event传入代表选中的值,如test方法,这里似乎也只要$event可以传入代表选中的值,其他的可能就是普通的参数,

  • Python使用函数默认值实现函数静态变量的方法

    本文实例展示了Python使用函数默认值实现函数静态变量的方法,具体方法如下: 一.Python函数默认值 Python函数默认值的使用可以在函数调用时写代码提供方便,很多时候我们只要使用默认值就可以了. 所以函数默认值在python中用到的很多,尤其是在类中间,类的初始化函数中一帮都会用到默认值. 使用类时能够方便的创建类,而不需要传递一堆参数. 只要在函数参数名后面加上 "=defalut_value",函数默认值就定义好了.有一个地方需要注意的是,有默认值的参数必须在函数参数列表

  • Android线程中设置控件的值提示报错的解决方法

    本文实例讲述了Android线程中设置控件的值提示报错的解决方法.分享给大家供大家参考,具体如下: 在Android线程中设置控件的值一般会与Handler联合使用,如下: package com.yarin.android.Examples_04_15; import android.app.Activity; import android.os.Bundle; import android.os.Handler; import android.os.Message; import andro

  • JPA默认值设置没有效果的解决

    目录 问题:默认值设置没有效果 解决办法 JPA为字段设置默认值 问题:默认值设置没有效果 springboot项目的JPA数据库表的类添加默认值,有2种方法 1.@Column(columnDefinition = "varchar(35) default '12345' ") 2.@ColumnDefault("12345") 要求:设置img字段默认值为/imgs/defunct.png 依赖 <dependency> <groupId>

  • AngularJS 中使用Swiper制作滚动图不能滑动的解决方法

    Swiper是目前较为流行的移动端触摸滑动插件,因为其简单好用易上手,受到很多前端开发者的欢迎. 今天在使用Swiper的时候遇到这个问题: 使用angularjs动态循环生成swiper-slide类,在swiper-wrapper里生成6个以上的滑动页,可是就是划不到第二页,尝试将longSwipesRatio的值修改到最小,仍然不起作用. <div class="swiper-wrapper" > <!-- =======循环部分======= --> &

  • 基于layui table返回的值的多级嵌套的解决方法

    我在学习layui的过程中遇到了table返回值的问题,如果服务器端返回给你的数据是多级嵌套的话,那你在前台是解析不了的,在table.js源码中 它渲染数据是用了 data = res[options.response.dataName] || [] 这个意味着它源码不支持嵌套数据 举个例子把 比如服务器端返回的数据中data>dataList>list 把这个数据返回给前段解析出来的是 res[data.dataList.list]类似这种的结构,当然解析不了,所以我写了一个方法处理返回的

  • IDEA2020 1.1中Plugins加载不出来的问题及解决方法

    进入File->Setting 如图,取消勾选,点击确认后重启,点击了以后等一会就可以正常显示 ps:下面看下解决IDEA 2020.1.1 找不到程序包和符号 问题描述 IDEA 2020.1.1 maven项目build的时候报错,找不到程序包,找不到符号. IDEA 2020.1.1 maven project: cannot find package, cannot find symbol. 思考 项目是maven,使用mvn clean package可以完成编译.说明问题不在操作系统

  • js文件中直接alert()中文出来的是乱码的解决方法

    解决方法如下: 在这句语句上面加上echo "<meta http-equiv='Content-Type'' content='text/html; charset=utf-8'>"; 以上就是小编为大家带来的js文件中直接alert()中文出来的是乱码的解决方法全部内容了,希望大家多多支持我们~

随机推荐