对比5.6与5.7

5.7 相对于 5.6 有着很多方面的改进，

• 改进 InnoDB 存储引擎，具备更好的性能

优化临时表性能
只读事务性能的改进
加速连接速度
复制性能改进

• 增强数据安全

默认连接才用SSL加密方式
安装后产生随机密码
强制用户修改密码或禁用用户

• 更好的优化器

文档里写的很清楚，对于很多方面都有性能上的改进。
比如：
`UNION ALL` 不再创建临时表；
让索引切换代价最小化等

• 原生支持 JSON 的类型和地理位置类型

文档类数据库的大火，也让 MySQL 增加相应的功能，再加上地理位置的类型，
之后的 MySQL 可以更便捷的扩展出新的功能。因为5.6的版本只能通过绕远路的
形式来实现相应的功能。

• 新增 SYS 库，5.6可以通过安装来增加

SYS 库包含了一系列视图、函数和存储过程，通过sys schema能够知道哪些
语句使用了临时表，哪个用户请求了最多的io，哪个线程占用了最多的内存，
哪些索引是无用索引等。很多数据是来自于 performance schema 和
information schema，但是 sys schema 信息源组织起来以提供有用的信息。

• 新功能

分页压缩
InnoDB 全文检索

5.7 终于 ctrl + c 不退出 MySQL了，感天动地。

升级的代价

• 线上的几十个客户需要一个一个备份数据，然后平滑升级。并且需要先升级几个客户观察情况，后续客户再慢慢手动升级。
• GROUP BY 在5.6中是会排序 GROUP BY 后的字段的，5.7不排序了，这个要额外注意。这就说明以前有些不是太规范的代码需要修改了，避免升级后数据排序不一致。
• 5.7的正式版发布已经两三年了，已经经历了很多公司线上功能的考验，但是还是无法百分百确定升级后的问题，毕竟复杂的改变都很难是百分百可控。

升级后我们的改进

• 性能的提升是毫无疑问的，但是想对我我们现在的系统能有多少的提升有待考证。
• 系统以后的可扩展性强，系统现有的有瓶颈的地方得到相应的改善。比如通过全文索引优化模糊搜索，现在主要是针对手机号码的模糊搜索。
• 更容易监控数据库设计的不合理之处，对于数据库的维护便利性也会相应的得到改善

如何去选择

5.7 相对于 5.6 的优势是显而易见的，但是升级相对于现有系统的稳定是有冲突的，这就是为什么大企业（移动、银行等），还是存在5.1或5.5的 MySQL 版本，因为他们愿意通过绕远路、增加配置等方式来维护系统的稳定。就现在的我们而言，是选择更好性能，以后可玩的花样更多；还是选择维持现有系统的稳定，这就是我们需要根据这两者做出相应的妥协。