mysql 5.5升级到5.7的坑

mysql 5.5升级到5.7后对数据库的要求更加严格了，所以我们在升级之后的一系列的操作都会失败。
具体有哪些sql_mode发生变化，我们可以查询

	select @@global.sql_mode;//查询全局的sql_mode,
	select @@sql_mode；//查询补充系统变量sql_mode;
	

常见的sql_mode模式
ONLY_FULL_GROUP_BY
对于GROUP BY聚合操作，如果在SELECT中的列，没有在GROUP BY中出现，那么这个SQL是不合法的，
因为列不在GROUP BY从句中

NO_AUTO_VALUE_ON_ZERO
该值影响自增长列的插入。默认设置下，插入0或NULL代表生成下一个自增长值。如果用户希望插入的值为0，而该
列又是自增长的，那么这个选项就有用了。

STRICT_TRANS_TABLES
在该模式下，如果一个值不能插入到一个事务中，则中断当前的操作，对非事务表不做限制

NO_ZERO_IN_DATE
在严格模式下，不允许日期和月份为零

NO_ZERO_DATE
设置该值，mysql数据库不允许插入零日期，插入零日期会抛出错误而不是警告

ERROR_FOR_DIVISION_BY_ZERO
在insert或update过程中，如果数据被零除，则产生错误而非警告。如果未给出该模式，那么数据被零除时Mysql
返回NULL

NO_AUTO_CREATE_USER
禁止GRANT创建密码为空的用户

NO_ENGINE_SUBSTITUTION
如果需要的存储引擎被禁用或未编译，那么抛出错误。不设置此值时，用默认的存储引擎替代，并抛出一个异常

PIPES_AS_CONCAT
将"||"视为字符串的连接操作符而非或运算符，这和Oracle数据库是一样是，也和字符串的拼接函数Concat
想类似

ANSI_QUOTES
启用ANSI_QUOTES后，不能用双引号来引用字符串，因为它被解释为识别符

这边因我的存储过程中的update语句中有分母为0的情况，所以升级到5.7之后存储过程的执行就会一直出现
division by 0的错误，一开始想出来了2个解决方案：

1.给分母上加上nullif(param1,param2)的函数
	nullif的意思是，如果param1=param2,那么返回为true,这个结果返回为null
否则的话返回的是param1的内容
这种方案虽然能解决问题，但是改起来太慢了，如果存储过程很多的话，又是重复工作量。

2.修改sql_mode
	因为数据库是放在linux上，但是用docker部署的，因为不知道mysql的映射的配置文件，所以很尴尬，只能
在navicat这边用语句处理，mysql一旦重启后就失效了。
	linux版的话修改下mysql.cnf文件，在文件中加入sql_mode的设置。
	windows版的话修改下my.ini文件，在文件中加入sql_mode的设置。
这里设置完之后都要重启才能生效。
	
	如果没法修改配置文件，我们在navicat中，执行语句也可以的
	(1)可以直接设置sql_mode为空
	set sql_mode=“”;
	set @@global.sql_mode =“”；
	flush privileges;
	（2）可以将sql_mode设置为非严格模式
	set sql_mode=“ANSI”;
	set @@global.sql_mode =“ANSI”；
	flush privileges;

以上只是本人遇到的其中一个小问题，不同的环境不一样，希望能解决您的问题。