升级到MySQL 5.7的几个理由

这是学习笔记的第 2075 篇文章

今天刚到工位，就收到了一大堆的报警邮件。提示有两个实例内存存在瓶颈，目前内存使用率已经超过85%，需要尽快调整。

我看了下环境，一个是5.5的实例，一个是5.7的实例，经过评估，发现这两个服务的缓存完全可以做下收缩，比如开放了8G,结果一下子就分配了快7G左右，难怪空间有些紧张，对于这个问题的修复，主要的参数就是innodb_buffer_pool_size,在5.5版本中需要修改后重启生效，而在5.7版本中则可以在线修改。

5.5的这个环境，我找业务方进行确认，然后停止服务重启，整个过程持续了不到1分钟，但是这个调整对于业务同学是可见的，而且还存在业务中断，相对来说不够友好。

而5.7的这个环境，则进行评估后，直接在线修改，整个过程也是秒级完成，但是无须找业务方进行确认，就实现了这个需求，算是尝到了升级的一个好处。

我简单做了下梳理，也是在最近的升级和迁移中的一些感受，为什么要升级到MySQL 5.7,或者称为升级到MySQL 5.7的几个理由。

1.在线调整innodb_buffer_pool_size

这个特性和Oracle的SGA自动管理有点类似，当然在线调整的前提是负载不高，如果是负载较高，还是不建议这个操作的，要知道缓存设置的大起大落，也是很可能导致宕机的，这一点在Oracle中已经栽过几次坑了。

2.sys schema

5.7版本对我来说，最具有诱惑力的特性就是sys schema,因为这个设计很全面，能够涵盖很多的业务场景，能够让数据库检查脱离了传统的处理方式，融入了业务场景，还是比较实用的。

3. GTID

尽管在5.6引入了GTID,但是我感觉在5.7里面才像回事情，GTID的方式能够提供很大的便利，尤其在一主多从，维护复制关系时，非常省心。

4.并行复制

延迟问题是老大难问题，在5.7中算是有了明显的改观。

5.用户和权限分离

对于运维侧来说，我觉得5.7的用户和权限分离的模式是比较优雅的，之前的大一统方案还是不够严谨。

show create user

show grants for

6. 辅助端口

在Percona分支或者是MariaDB里面，是存在辅助端口的，这样一来业务导致的不可访问访问，进退两难，如果我们有了辅助端口的特性（参数extra_port），就可以淡然一些，避免最暴力的数据库重启。

7.半同步

5.7的半同步相比来说要优越一些，在实现细节上是更加完善了。

8.DML执行计划

5.5版本中想要查看一些DML执行计划是存在限制的，通常都会把DML语句转义为等价的DQL(select), 5.7的这个特性就比较贴心了。

9.MGR，InnoDB Cluster

从数据库架构设计来说，MGR绝对是一个重点特性，官方一出手，能够对现有的生态体系做到有效补充