大话MySQL之爱恨情仇

曾经终败给现在 2022-12-17 05:21 184阅读 0赞

在数据库的发展过程中，安全-->稳定-->高效-->低成本四个有序的要点一直如影随形，后者离开前者就是空谈。10月19日晚上MySQL发布了8.0.22版本，其中一个新功能（**Automatic connection failover for Async Replication Channels**）引起我的注意，也很感兴趣，作为一个DBA老兵，百感交集，在过去的20多年，故障切换功能一直是三方后娘工具在主导，是几代DBA的痛，互联网最流行的数据库，在这块一直为人诟病。此功能还没有测试，不管如何，至少在这块官方终于开始出手解决了。夜深人静，整理了一下思路，对于MySQL产品截至目前的发展情况，做了一下总结，基本走以下几个方向发展：

1.  主从同步方向：异步同步到半同步，再到增强半同步，再到组复制；走同步的安全策略，到提升同步的效率，走单线程复制到并行复制，致力于降低主从延迟问题，但相对的同步绝对的延迟伴随其发展全过程至今。
    
    ![format_png][]
    
    ![format_png 1][]
2.  性能优化方向：多线程，线程池（原版MySQL的企业版支持，社区版不支持）；各种日志各种独立，截止8.0.22版本，保证安全与问题记录的日志基本全部独立了，可以动态调整参数单独控制关闭和打开；重构核心引擎Innodb，优化各种锁，独立锁，优化事务操作等。各种的一顿骚操作优化，使得最新版的MySQL性能也达到了前所未有的高度。
3.  多模数据库方向：关系型数据、JSON半结构化数据、对象数据、内存型以及全文检索引擎等等多个数据引擎，走支持OLTP业务开始拓展至OLAP业务（Oracle云上支持的Analytics Service），虽然只有它自己的云上支持。
4.  借鉴其他数据库方向：最大的借鉴为ORACLE数据库，现在的各种语法和一些用法越来越ORACLE了；借鉴了MongoDB的一些功能，如MIC（MySQL innodb cluster）中的相关设置、自动搭建从节点的克隆功能等，不过在使用中确实有点复杂。
    
    ![format_png 2][]
5.  智能化运维方向：支持各类在线DDL，对业务几乎无感知，这个为以后智能自助动态优化索引打下坚实的基础；重点的性能参数差不多都支持在线修改；支持持久化动态调整参数，保证重启后参数与重启前一致；关闭MySQL时可以把内存的热数据持久化到硬盘，启动时重新由硬盘加载到内存，减少了数据库预热，使数据库重启后快速进入之前的战时状态；SQL语句的重写功能，不变更业务代码情况下重写SQL；可以支持根据硬件配置，启动时自动调整部分参数配置，虽然可自动调整的参数有限，结合前几项，为未来MySQL在智能参数调优与自我优化方面、自治数据库的发展奠定了基础。
6.  提升安全性方向：健全的日志，保证在各种异常状态下不丢失数据，这也是数据库最基本的要求，MySQL也一直在努力增强再增强，努力打造金融级数据库；增强的用户验证方式caching\_sha2\_password，强化认证模式，增加用户认证串被暴力破解的难度。但最大的安全功能failove却一直没有。
7.  降低成本方向：这个路线进度有点慢，目前在innodb的压缩上有所发力，压缩比有所改进；在增强用户使用体验，简化使用操作等人力成本上一直在努力，不过有些操作比较畸形，操作配置使用复杂，比如MIC的配置。

![format_png 3][]

固然MySQL深受广大人民喜爱，装机量也很大，其本身也特别优秀，但爱之深恨之切，依然有许多不足：

1.  在自动创建从节点，组复制刚自动增加新节点竟然必须要有数据库初始化开始全部的Binlog日志才行（感觉设计这个方案的产品脑仁有点小），否则就需要使用mysqldump手动搞定，至今增加新节点的操作依然很骚，依然不方便，操作依然复杂，反观MongoDB就简单多了，不管是操作还是运维成本都很低。
2.  MySQL经过20多年的发展，至今故障切换依然依赖三方工具，故障自愈方面好好改进一下，不过至今为止，不是很理想。其实在MySQL的JDBC中很早就类似MongoDB支持链接多数据库多节点配置，但是自身没有故障自动检测和切换功能，这个功能一直是个摆设。MySQL8.0.22版本终于支持故障启动切换，走配置参数来看，节操碎一地，估计差MongoDB的这个功能不是一星半点。期待官方在这块投入更多的人力物力，使MySQL结束这种原始操作状态，提升一下运维人员SLA和业务的不可用时间。
3.  drop table/database删除操作的优化，目前删除大表和库的时候对数据库性能影响巨大，甚至能把数据库给干挂了。
4.  假删除或延时删除库表，做数据库的删除回收站，给数据库定制后悔药。
5.  MIC目前是个鸡肋，估计也没啥人用，router和shell组件完全可以集成进MySQL中，组件越多运维等成本越高，这种管理模式用中间件不也挺好，还能私人订制（毕竟修改中间件的成本没有MySQL源码的高），配置管理复杂，向MongoDB复制集看齐不香嘛？
6.  每个产品都有其核心竞争力，MySQL现在的产品有忘记初心（安全、稳定、高效、低成本）的嫌疑，花活太多，想做的东西太多，想要参考其他数据库功能也很多，all database in MySQL行的通嘛？真的能一统数据库江湖唯吾独尊嘛？

**传说中的MySQL存储与计算分离官方是否会支持？**

数据库的存储与计算分离架构这两年很火，这也是数据库发展的一个方向，一方面硬件技术的进步，支持弹性伸缩，合理利用资源，降低成本，二来高并发大数据量的业务需求，特别是万物皆为云的当下，这种架构的出现确实应时应景。MySQL如果支持这种架构，必然要对MySQL-Innodb的存储引擎做大量的修改，而且还要有自己对应的分布式文件系统，当前的MySQL架构可能要做大量的调整。MySQL官方为了进一步降低主从同步延迟，可能会支持物理复制来优化延迟问题。至于存储与计算分离个人感觉官方不会支持，至少在在短时间内不会支持，也许在MySQL 13中会支持，因为我河南老乡王守义说过十三香^-^

集多种数据库优点之大成，不忘初心，海乃百川，有容乃大，感觉MySQL还是不够包容和开放。很多现成的成功案例和方案思路，借鉴过来即可，何况官方的研发人员也是全球顶级的，咋就学不会呢？很多事情咱也看不懂，咱也不知道，咱也不敢问，谁知道哪，说不定明天一觉醒来MySQL来个华丽转身，穿个新娘装跑步进入智能化、自治化数据库时代呢？

全文完。

Enjoy MySQL ：）

[format_png]: /images/20221123/0c388dc3a0a647cab92e475b68a3c499.png
[format_png 1]: /images/20221123/7775c6e42c69438a8c5936f7407aa2dd.png
[format_png 2]: /images/20221123/6d33205d4ef546749d959fc1f80b005b.png
[format_png 3]: /images/20221123/838e585caabc43df8fcb63520cab490f.png