MySQL版本升级注意事项

1、升级是一件风险极高的任务，备份重于一切。

2、了解新版本变更的信息（哪些不再兼容，不再支持哪些功能）。

1、确认新版本是否有重大变更

2、注意 SQL mode 的变化，比如：MySQL5.7发生了SQL mode的变化，对不再支持的SQL mode，部分SQL会跑不通，可以清空SQL mode，跑完之后在设置SQL mode。

3、升级成功后，确认业务SQL是否可以跑通，程序层是否都正常。

4、在升级完成之后，一定要在测试时使用和线上版本相同的程序，测试是否存在问题。

5、存储引擎的变化，比如：在未来的5.8版本，不再支持myisam 引擎。

6、注意字符集的乱码问题。

7、升级过程中多次启动建议加上 --skip-grant-tables和--skip-networking 参数，来保证没有任何的应用连接，让升级过程更加安全。

实际这里是是一个delete in语句。

大概就是这样一个语句，处于preparing 状态，问delete为什么会处于这个状态？

对于preparing状态一般归结为优化阶段，并还没有进入实际的语句执行阶段。但是这里有所不同。并且我们知道一般delete执行慢一般状态会处于，

但是这里是preparing状态。那么为什么会处于这种状态呢？简单分析一下。

我们知道5.7的delete in实际上还是用的DEPENDENT SUBQUERY。这个类似exists的 *** 作，都会用外层查询驱动内层。稍微跟了一下5.7的delete in（不做详细研究），发现所有的query block并没有完全完成优化，实际上这种子查询会在调用Item_subselect::exec的时候通过

进行判断，如果unit->is_optimized()判断为false，则会调入unit->optimize(thd)，对subquery的query block进行优化，而优化结束后查询的状态会被设置为preparing。也就出现了这种现象，如下：

这种现象当前看起来是5.7（5.7以下没有测试）中DML语句带in/not in常见的，也可以归结为状态转换稍微考虑欠妥，可能开发大佬也没意识到这个状态已经变为DBA诊断问题的一个主要手段。

而到了8.0状态已经更加精细，有了一些细微的变化，而且8.0.21后支持DML 中的in使用semi join(not in还不行，但是状态是executing）优化。所以我们简单的将其归结为正在执行类似sending data状态即可。需要优化的是将这种delete改写为联合delete形式。

MySQL 5.7 已经开发两年了。相比 MySQL 5.6，有特别多的改进。团队主要关注速度，性能据报告是比之前版本提升了 2 至 3 倍！

新特性列表，主要改进：

提升 MySQL 安全性

改进了安装程序

MySQL 5.6 中，mysql_install_db 在数据库创建的时候提供选项来生成 random password。

MySQL 5.7.4 中，可以跳过 -skip-random-password 选项来默认生成随机密码。

MySQL 5.7.5 中，还是默认生成随机密码，但是选项修改为 –insecure

而现在，MySQL 5.7.6 废弃了 mysql_install_db，使用 mysqld –initialize (formerly known as “mysqld –bootstrap,” now deprecated.) 替代。

---