MYSQL 知己知彼百战百胜 从MYSQL 8.019 说起

此前关于MYSQL的文字终止在一段“吐槽” MYSQL的文章，不少人估计认为从此以后就只有PG 和 分布式的一堆数据库，NO NO NO ， MYSQL 虽然问题多多，但一直在进步，这点不能被否认。

今天就说说 MYSQL 从 8.019 后面的一些关键性的升级的功能，不用的人可以看看人家有什么优势， 用的人更可以知道，我为什么要升级到这个版本的MYSQL 。

从8.019 这个版本MYSQL 推出了innodb replicaSet, 有些人问，不是有innodb cluster 怎么又回到原点了，有要进行异步复制，实际上不是的，MYSQL本身虽然一直在加强以paxos 协议为主的INNODB CLUSTER 的高可用方式并且提供了基于MYSQL SHELL 为主的变成方式的高可用操作方式以及MYsql ROUTER的轻量级的中间件，为自己的MYSQL的提供一个分布式的方案，但实际上估计MYSQL 也意识到，单条腿走路的方式并不稳定。

所以转过头又开始在传统的复制方式上，来一个回马枪，  innodb replicaSet,  撕开包装，mysql的  replicaSet就是我们一直在用的异步复制的增强版。

根据本部上的说明

1   mysql replicaset 支持多个从节点，与一个主节点，但从添加和减少节点的方式上，以及借鉴了 innodb cluster的方式来进行节点的处理通过mysql shell来控制和管理，同时这个MYSQL的异步复制支持 clone的方式来进行mysql的新节点的添加，这点可以说是一个非常大的进步，减少了手工管理节点添加的麻烦。同时还用自己的 mysql router 的中间件为这个异步复制进行连接方面的管理，你不在需要第三方的一些工具如 haproxy ,或者其他的方案，所有的东西都是mysql 本身的东西。

  以上是 MYSQL 8.019 做的最大的一件“好事”。

8.020 做了另一件好事 binary log compression , 这点其实是基于上面的8.019后的延续，数据节点之间的数据复制都离不开传送日志，无论是物理的还是逻辑的，基于mysql的逻辑日志一直都不占便宜，所以数据量大日志在网络中疯狂的传送，这点一点都不优美，8.020，可以在MYSQL的从传输到写入整个的流程中，数据一直是压缩的。

这与一些所谓的压缩不同，所谓的压缩是，我传输时压缩，到目的地解压缩，MYSQL的 binlog compression 是在整体的过程，包括写到中继日志中都是压缩的方式，这就让主库 从库 以及网络都享受到了压缩的好处。

压缩的方式中可以通过 binlog transaciton compression  来控制MYSQL到底是不是采用压缩的方式，或者通过binlog transaction compression level zstd 从 1 到 22 来选择压缩的级别。如果你CPU 强悍当然可以选择最大的压缩，在1到22之间来寻找你和物理机之间的平衡。

这个改进有助于MYSQL在高并发大数据量的场景中采用任何的 INNODB CLUTER  OR  INNODB RELICASET 并为其提高性能。

8.021  干了一件“有意思”的事情， diable  redo logging ，对没错没听错，取消redo log， 这个功能听起来不可思议，但实际上针对制作新的节点并让大量的数据加载到新的节点，避免在加载数据的期间进行REDO 和 DW的工作，提升整体数据加载的速度，当然如果你敢在正常的生产系统中来关闭REDO，那么在突然关闭MYSQL 服务后，你就会发现他会拒绝你的MYSQL再次启动

[ERROR] [MY-013578] [InnoDB] Server was killed when Innodb Redo logging was disabled. Data files could be corrupt. You can try to restart the database with innodb_force_recovery=6

此时也只能说你活该，谁让你随便关闭REDO

关闭的命令也很简单

ALTER INSTANCE DISABLE INNODB REDO_LOG;  即可

8.022 又干了一件事情, Automatic connection failover for Async replication, 这个功能很有意思，大致的意思就是在异步的复制中，如果一个主节点失效，那么他会从你已有的预备节点中，找一个新的源来尝试加入到复制中，这个功能和MONGODB的从库转移的功能其实是类似的，主库失败，从库直接从已有的列表中找一个节点尝试连接并进行后续的数据复制。

8.023

又做了关于  group replication的 automatic connection failover for async。 

从上而下，从8.019 到 8.023 MYSQL 在2020年主要的整改对象就是高可用中的性能问题， 从异步复制的自动化管理，到日志传输的压缩，再到数据到从节点生成时提高性能。 其实MYSQL 在数据复制和高可用方面的进步是显著的。

同时mysql 在去年也没闲着，和 PG 以及 ORACLE 身上都薅羊毛，把  prepared statements 的功能在 8.022上实现了，把 set tablespace autoextend_size  的功能在8.023 实现了。 当然还有一直是短板的窗口函数，也是在提高，终究MYSQL还是想在已经很差劲的数据分析的功能中，找到点自信，但被PG 在这方面甩了几条街，想要追上那就还的好几年的功夫。

最终在invisble index 后，又在8.023加入了invisible columns, 根据一个蹩脚人士的解释，为什么又研发了一个invisble index ,主要的原因还是在老的应用中如果使用了select *  的方式，并在表中加入了新的字段，那么新的应用可以通过指明 隐藏的字段，来让字段展示，美其名曰，兼容性。呵呵

当然MYSQL 还在往前目前最新的MYSQL 是8.028，不过看下来，如果之前还抱着MYSQL5.7的知识来审视 MYQL 8.019 后的版本，嗯，努力学习吧，新的想法和知识有多了。