vlambda博客
学习文章列表

现在是不是升级 MySQL 8.0 的好时机？

Hello 大家好！这里是由爱可生开源社区赞助和 IMG 社区联合举办的《MySQL冲冲冲》节目，第一季一共八集。

我穿的 T 恤上面印着：一个有态度的 MySQL 社区 和 IMG 社区 Logo；一个有深度的 MySQL 社区 和 爱可生 Logo。非常感谢爱可生开源社区给我们的支持，大家可以看到我们在每次直播节目中给大家准备了非常丰厚的礼品，希望大家关注爱可生开源社区和我们的 IMG （Inside MySQL）社区。

话题时间

现在我们来讲一下《MySQL冲冲冲》第一期的话题，也就是：MySQL 8.0 现在是否升级的好时机？

1、 快速加列

首先，快速加列功能十分硬核，因为加列操作对运维 &DBA 来说，这个需求简直是太普遍了。每个 DBA 每周要处理大量的加列变更的工单，所以有了这样的一个功能特性，能使得我们 MySQL DBA 非常容易的去做这件事情。

MySQL 5.6 版本提供了在线加列的功能，但是对业务还是会有一定影响，对一些大表的加列操作都是通过 pt-osc。但 pt-osc 本身又有很多限制，如果有大事务也会有比较大的影响。所以说 pt-osc 虽好，真的要做这些事情，DBA 需要不断地验证，实时的监控变更加列操作是否对线上业务产生影响。有了快速加列这个功能的话你会发现，这就是秒加！按下回车键就列加完了。所有加列的默认值都是初始定义的，只有行发生变更，新加列值才发生变更。

该功能也是由腾讯互娱数据库团队提的一个 patch，我们也能看到中国的 MySQL 内核开发人员能力也是非常强的。也希望未来有越来越多的同学能参与到这样一个世界级的开源项目中贡献自己的一份力量。并且能合并到主版本中，对于内核开发人员这是一件非常棒的事情，相信他们的成就感会非常非常高。

2、Atomic DDL

这个功能从整体架构上是一个非常非常大的变更，因为要实现 Atomic DDL 的本质是将所有的元数据表从 MyISAM 引擎变更为 InnoDB 引擎。这个变动非常非常大从代码量来看，这会导致一些锁的机制，比如：元数据锁，都会发生内核代码层的一个修改。

功能本身没有什么好特别讲的，就是把 DDL 操作原子化。之前我们遇到 DDL 操作碰到 Crash，再启来后比较讨厌，会有一个临时文件一个 frm 文件要做处理，现在就不用了，因为是原子的。但发生 DDL 并发生 Crash 这种概率万分之一甚至更低。但基于这个特性对未来最大的影响是 InnoDB 可以在做很多其它的事请，比如transactional DDL，就像微软的 SQL Server，就是 DDL 也是可以回滚的。基于现在 InnoDB 的元数据表，要做这件事情本身不是特别难。如果做内核的同学感兴趣可以去实现一下，从 Atomic 编程 transactional。

这个改动是一个很基建的，未来对 InnoDB 的发展，不止于 Atomic 这一个功能。大家可以发挥想象，非常棒的一个功能！

3、Hash Join

这个功能之前也是其它数据库爱好者比如 PG DBA 吐槽 MySQL 不支持，那么 8.0.18 版本支持，8.0.19 版本去掉了早期 Join 算法  Block Nested-Loop Join。现在如果优化器选择没有索引的话，就直接使用 Hash Join。这功能还是非常棒的，而且比 MariaDB 实现的要好。

大家知道 MariaDB 在 5.5 版本也支持一个所谓的 Hash Join，但是实现的非常非常弱。为什么这么说？第一点，它不是优化器的选择，是你要指定选择 Hash Join。第二点，如果表大于内存是不支持的。MySQL 8.0 把这个问题解决的非常好，如果超过内存可以基于磁盘。唯一要改进的是，目前不能利用多线程特性。受限于此主要还是优化器本身的限制，8.0 版本本身的优化器对于并行度的支持还是非常弱的，现在只支持对 COUNT(*) 主键的扫描去支持并行。

我相信未来这个功能对多核多线程的支持会实现，现在对优化器的重构也是为了实现这个目的。Hash Join 对业务有多大的帮助是需要探讨的。MySQL 成功与否是否取决于 Hash Join 呢？我觉得并不是。MySQL 二十多年没有 Hash Join，大家也用的好好的。当推出 Hash Join之后，是一个锦上添花的。例如报表类的操作我们可以利用到 Hash Join 这个功能了，比如对我自己来说，有很多爬虫拿取数据，之后对数据做报表分析。虽然数据量达到百万级也不是特别大，但是需要接入 Power BI 去做展示，用 MySQL 速度还是比较慢，更新到 8.0 之后就快了非常多。

对于风控类业务来说，数据量不是特别大，需要做分析。而且表的变化非常大，加列需求也比较多。我觉得 MySQL 8.0 的加列和 Hash Join 对于风控类型的业务来说有很大的帮助。

4、Group Replication

对于 MGR 最重要的一点就是，如果要使用 MGR 功能，我强烈建议大家使用 MySQL 8.0 版本而不是 5.7 版本。因为 5.7 版本有很多 Bug 没有修复在 8.0 上修复了。对于网络分区的代码强壮性和稳定性，8.0 比 5.7 做的更好，并且提供了一些新的参数来处理一些网络分区的情况。因为之前也踩了很多坑，所以如果你要在生产环境使用 MGR 强烈建议升级或直接使用 8.0 版本。

现在是不是升级 8.0 的好时机？

姜老师觉得，现在已经是一个升级 8.0 非常非常好的时机了。因为 8.0 已经推出两年多的时间了。从软件生命周期来看，对于 5.7 只会修复 Bug 没有新特性了。另外 8.0 版本本身发布的方式也发生了很多变化，使用了小版本、快速迭代功能方式。也就是大家会发现从 8.0 开始，每个小版本都会有大的特性。这与 5.5、5.6、5.7 是非常大的一个区别。

大家回忆一下， 5.6 版本推出了基于库的并行复制，5.7 推出了 MTS，是在两个大版本提供的。但是 8.0 你会发现每个小版本都会有很大的特性。比如 8.0.12 是第一个 GA 的版本，8.0.13 就推出了快速加列，8.0.17 推出了 clone plugin 备份插件，8.0.18 推出了 Hash Join，8.0.19 推出了隐藏索引、降序索引。MySQL 的发布方式发生了翻天覆地的变化！MySQL 5.7 就享受不到这些特性。

从软件生命周期和发布方式上看，现在都是升级 8.0 的好时机。据我所知，很多金融公司、银行，已经在生产环境中部署了大量 8.0 的版本。

认证机制

我们在使用 MySQL 8.0 时最大的变化就是它的认证机制。原来（5.7）的 native_password 变成了 sha_256。如果 MySQL 升级后想对业务无感知，需要把验证方式设置成 native_password 模式来兼容 5.7，其它方面影响还好不是特别大。按照正常的升级方式从 5.7 升级到 8.0，你就能享受到 8.0 的特性。

最后

作为一名资深的数据开发者或者 DBA 也好，我看到了官方对 MySQL 的诚意。他的确开发了一些非常棒的特性，符合我们业务的需求。强烈建议大家升级 MySQL 8.0 版本，是绝对值得你去升级的好版本。

致谢

最后，还是要感谢爱可生开源社区对于《MySQL 冲冲冲》这个节目和姜老师本人的大力支持。爱可生本身是一家 MySQL 服务公司，如果大家对 MySQL 有任何问题也可以向他们寻求帮助。

第二期话题：

“MySQL DBA 职业生涯发展规划，35 岁到底会不会被裁？”

将有神秘嘉宾与姜老师连麦互动，作为 DBA 的你不要错过哦！

同时，爱可生开源社区也会赞助本次节目的分享，每场直播都有礼物赠送。