记一次mysql5.5升级到8.0的过程

记一次mysql5.5升级到8.0的过程

背景说明

本次项目使用的若依框架，该框架使用mysql做为后台数据库。实际上对mysql并不是很熟，常用的Oracle。根据网上查找资料部署环境，测试时使用的mysql版本是5.5.2，当时认为足够使用，没有使用更高版本。
项目大后期，需要接入数据源突然增多，数据量太大，处理（指group by）50万数据执行时间27s，优化语句不起作用，根据网上查找修改mysql配置增加缓存等都不起作用。
将语句发给同事，在他自己笔记本执行需要8s，他的mysql版本是5.7。将他的my.ini文件拷贝过来发现很多参数不能使用，网上查询报错信息才知道是5.5不支持。
计划将数据库升级到5.7，但是查到mysql8比mysql5快两倍，索性直接升到8。

升级方式

根据网上资料两种方法：
1.更换二进制文件……我没有尝试
2.先部署MySQL8环境，然后将MySQL5.5数据导入到新环境。我选择的方法

升级过程

1.MySQL8下载以及安装

网上很多资料参考：

Mysql win64 8.0.25 安装【最简单的步骤，无坑】

需要注意的是直接在服务器上安装就可以，不需要先卸载或者删除原数据库，因为后续还会用到原数据库
在上述安装说明的设定服务名环节起一个区别于原数据库的新名字即可，但要修改注册表里的路径。

2.数据导入与导出

经过不断尝试，发现其实很简单，直接使用navicat软件中的工具将原数据库的数据导入到新数据库就行。
因此如果服务器是内网环境不能和笔记本联通时，在服务器本机保留原数据库就派上了用场。

测试过很多用navicat导出的sql文件，mysqldump导出的sql文件速度都不快，这种是最简便快捷的。

3.采坑

（1）导入数据报错，时间为0000-00-00 00:00:00格式不能保存

根据资料设置sql_mode属性
my.ini文件中[mysqld]下添加配置
关于sql_mode详细说明参见
mysql的sql_mode合理设置

mysql8相对于mysql5.5更严谨，我在mysql5中有将date类型与‘’比较，在mysql8中会报错

（2）导入慢

mysql定义的写入日志模式和提交模式导致导入慢，详细解释见下

nnodb_flush_log_at_trx_commit 参数
安全性考虑，这个参数默认是 1
innodb_flush_log_at_trx_commit 默认值为 1，可设置为 0、1、2
innodb_flush_log_at_trx_commit 设置为 0，log buffer 将每秒一次地写入 log file 中，并且 log file 的 flush (刷到磁盘) 操作同时进行。该模式下，在事务提交的时候，不会主动触发写入磁盘的操作。
innodb_flush_log_at_trx_commit 设置为 1，每次事务提交时 MySQL 都会把 log buffer 的数据写入 log file，并且 flush (刷到磁盘) 中去。
innodb_flush_log_at_trx_commit 设置为 2，每次事务提交时 MySQL 都会把 log buffer 的数据写入 log file. 但是 flush (刷到磁盘) 操作并不会同时进行。该模式下，MySQL 会每秒执行一次 flush (刷到磁盘) 操作。
sync_binlog 参数
sync_binlog 默认值为 1，可设置为 [0,N)
当 sync_binlog =0，像操作系统刷其他文件的机制一样，MySQL 不会同步到磁盘中去而是依赖操作系统来刷新 binary log。
当 sync_binlog =N (N>0) ，MySQL 在每写 N 次 二进制日志 binary log 时，会使用 fdatasync () 函数将它的写二进制日志 binary log 同步到磁盘中去。

为了快速导入，设置如下：
innodb_flush_log_at_trx_commit=0
sync_binlog=2000

最后还是听从网上建议将innodb_flush_log_at_trx_commit=2

（3）函数不能导入

mysql8中没有mysql.proc
导入时提示函数导入报错，存储过程可以
提示如下：

Err] [Dtf] 1418 - This function has none of DETERMINISTIC, NO SQL, or READS

(4)其他