mysql 5.7 EOL 的代替方案调查

mysql 5.7 EOL 的代替方案调查

一、可选方案

方案一：直接升级到8.0

做出此选择的MySQL5.7用户占比较高，此类用户对此问题早已了解，并且在半年前就已经开始应对工作。MySQL 5.7升级到8.0不仅仅是更换一个数据库版本而已，因为8.0与5.7在技术上有较大的差异，CBO优化器与SQL引擎都有一定的不同，因此数据库升级后应用需要做全面的测试，对于不够兼容的部分代码做一定的修改才能确保顺利迁移。因此采用第一种路径的用户，需要做一定的提前准备。

但即使升级到MySQL 8.0，也只是一时的解决方案，仍然无法避免未来的停服问题。不能解决 MySQL 架构导致的扩展性、高可用性和处理现代云原生架构相关的固有挑战。同时，它还依赖于Oracle接下来的战略方向，比如对MySQL产品的支持力度。

网上搜寻资料，MySQL 8.0 于2026-4-30日结束支持

升级教程：https://zhuanlan.zhihu.com/p/655012258

方案二：直接迁移到MySQL兼容的国产数据库

有一部分客户考虑到信创的问题，原本就已经计划对数据库进行国产化替代，准备一次性到位。如果用国产数据库替代，那么可以选择的路径也很多，很多国产数据库产品就是MySQL生态产品，比如腾讯TDSQL、万里GreatSQL、中兴通讯GoldenDB、Oceanbase、阿里PolarDB-x等。如果不需要使用存储过程，还可以考虑TiDB。很多国产数据库也有MySQL兼容模式，虽然不能完全兼容MySQL，应用做少量的修改也可以迁移过去。达梦、人大金仓、GaussDB等数据库都有MySQL兼容模式。直接迁移到国产数据库的优点是从根本上完成数据库国产化替代。

不过缺点也很明显，一方面是迁移需要一定的资金，也需要一定的时间，另外一方面是国产数据库许可证采购总体成本不低。

在这些开源产品中，以 GreatSQL、PolarDB-X 等为代表的一些产品均取得不俗的成绩。它们通过构建国内自有开源生态社区，稳步推进生态发展。通过活跃的开源社区，不断更新迭代产品发展，快速响应解决社区问题，完善产品在不同业务场景下的需求，逐步形成更为符合中国特点的生态体系。

以 GreatSQL 为例，通过增加如并行查询、线程池、MGR增强、SQL兼容增强、国密算法等特性及能力，提升在高性能、高可用、易用性、安全性上的表现，为国内用户提供了MySQL5.7停服替换的一种更好的选择。

附：

国内的MySQL开源分支案例分析

近几年，国内涌现出了诸如GreatSQL、PolarDB-X、StoneDB、TenDBCluster-TenDB、AliSQL开源社区等一批基于MySQL开源分支，并已经初步构建多方参与的社区生态，在应用落地、社区活跃度、代码贡献等层面围绕自身特点进行不断完善。

但很多人的认知仍然停留在过去，关于“国内的MySQL开源分支能用吗？是否会涉及知识产权侵权？”这一问题，至今还在被持续热议。

答案很明确：不会有涉及知识产权侵权的问题。陈书俊的文章《七问七答理清MySQL开源许可》已经详细回答了这个问题，这里不再赘述。

对于国内MySQL开源分支是否能用的问题，答案是当然能用

方案三：采用第三方 MySQL 商业版本

像MariaDB 和 Percona Server这样的MySQL分支版本是由第三方公司独立开发，为MySQL用户提供了替代路径。

优点：这些分支版本通常能够比MySQL本身更快地引入功能和性能改进。转向分支版本可以依旧获取持续的支持、与MySQL兼容的特性的熟悉性以及潜在的增强功能。

缺点：与MySQL一样，这些分支版本在处理高并发的写入密集型工作负载，或在分布式架构中部署时仍面临挑战。此外，支持的力度可能有所不同，一些企业可能不愿意对由社区驱动的项目提供更多的支持。，但这个选项在当下国产替代的浪潮下，大多数企业中似乎已经选择忽略。

方案四：迁移到分布式数据库

如果现有的应用程序需要超出单个 MySQL 实例所能提供的可扩展性和高可用性，那么分布式数据库（如 TiDB）可能是一个合适的选择。

优点：分布式数据库将传统关系型数据库管理系统（RDBMS）的优点（ACID 特性、对 SQL 的支持）与 NoSQL 系统的优点（水平可扩展性、高可用性）结合在一起。特别是 TiDB，完全兼容 MySQL 5.7，使得迁移变得更加容易。

缺点：迁移到分布式数据库的过程可能需要进行全面评估，而不仅仅是简单地升级 MySQL 或切换到分支版本。虽然 TiDB 兼容 MySQL，但可能不支持某些 MySQL 特定的功能，并且可能需要对现有的应用程序代码进行一定范围的调整。

TiDB 是由 PingCAP 开发的领先的开源分布式数据库。它无缝地结合了关系型数据库和 NoSQL 数据库的优势，将传统关系型数据库管理系统的 ACID 特性、 SQL 兼容性与 NoSQL 系统的水平可扩展性相结合。

以下是 TiDB 提供的主要功能的详细介绍：

• 水平扩展性：TiDB 的分布式架构允许数据自动分片到多个节点上。随着工作负载的增长，您可以轻松地向集群添加更多节点来处理不断增加的需求，而不会出现显著的性能下降。
• 高可用性：TiDB 通过在多个节点上复制数据来保持数据的冗余，并实现了自动故障切换。即使集群中的一个或多个节点故障，也能确保您的数据保持可访问状态。
• 强一致性：在许多分布式数据库中，一致性和可用性之间存在权衡。但是 TiDB 不是这样。它使用一种称为 Percolator 的分布式事务协议，保证了快照隔离一致性，确保集群中的所有节点对数据具有一致的视图。
• MySQL 兼容性：TiDB 支持 MySQL 协议，并且与 MySQL 语法具有广泛的兼容性。这意味着许多现有的应用程序、框架和针对 MySQL 设计的工具可以与 TiDB 一起使用。
• 实时分析：TiDB 利用 混合事务/分析处理（HTAP） 的能力，实现实时运营分析。TiKV、TiFlash 可按需部署在不同的节点上，解决 HTAP 资源隔离的问题。TiDB 提供了一个统一的平台，用于即时高效地分析运营数据。
• 云原生架构：TiDB 设计时考虑了云原生的原则，因此非常适合在云环境中部署。它支持 Docker 和 Kubernetes 等容器化技术，并集成了阿里云、AWS、GCP 等云平台。

方案五：不变，继续使用MySQL 5.7

数据库都是在内部使用的，因此把网络安全的边界扎牢，哪怕有安全漏洞，也不升级，不改变，等到应用系统升级的时候在考虑升级或者更换数据库。

选择这条路线的用户比例不低，这条路线的用户比例也不低，这条路径成本最低，不过要承担一定的安全风险。采用这条路线的用户把那全依托在网络安全和边界安全上，通过扎紧篱笆来防止安全事故。

方案六：换门，mysql直接更换数据库种类，转向另一个开源数据库PG阵营

和摄影界换门一样，采取这条路径需要下很大的决心。因为以往的应用都要修改数据都要迁移，以往积累的应用开发与运维经验也都要放弃。

方案七：对于公有云用户，依托平台再支撑一两年，在一两年中在选择方向

公有云厂商还会对mysql5.7提供一定时间的延长支持。公有云用户先观望一年在选择稳妥的技术路线的比例是比较高的。这条路线获得了一定时间的缓冲，以便做出更科学的决策，不过仅仅是过渡期的临时做法。

二、推荐方案

最主流三种方案对比

近期在中国信通院主办的2023 OSCAR开源产业大会上，发布的一份《开源数据库生态发展研究报告》上提出，以金融行业为例，收集来自用户的的反馈。从下图所示的用户选择来看，替换为国产数据库是主流的选择，选择升级到8.0次之，仍然冒险使用 5.7 版本很少。

针对这三种可行的技术路线，做了个简单的雷达图分析。图中的维度对比是来自上文的考量因素。

图中由内到外，对应迁移难度从难到易、成本由高到低、其他因素均从内到外为高到低递减，也就是说越靠外侧，越是优选之策。

那么从下图可以看出，国内开源方案相对比较均衡，且全面优于升级到8.0版本的方案，后者在长期发展上有优势。

而与国产商业数据库对比来看，后者的优缺点更加鲜明，部分对比项上有明显的优势，但同样也存在明显的劣势，主要表现在成本及兼容性上。

因此用户如何选择，需综合考虑自身的情况。下文将重点对比下各个维度。

倾向性：《开源数据库生态发展研究报告》发布 GreatSQL为MySQL5.7最佳替代方案！

9月21日，在中国信通院举办的2023 OSCAR开源产业大会上，《开源数据库生态发展研究报告》正式对外亮相。该报告针对MySQL数据库发展现状、技术创新、产业应用三方面梳理了发展情况，并对我国基于MySQL技术路线的开源数据库产业进行展望。

随着信息化建设的不断深入及国内开源数据库技术水平的增强，国内MySQL技术路线开源数据库从以下五个维度进行技术创新，打造最符合国内用户需求的开源数据库。

一是组复制（MGR）技术增强数据一致性；

二是MySQL双活架构实现数据库高可用;

三是推动数据库OLTP、OLAP性能优化，突破MySQL性能瓶颈；

四是通过密码限制增强、级联权限回收能力筑牢数据安全防线；

五是打造多种数据库迁移方案助力MySQL上云。

国内开源数据库蓬勃发展

GreatSQL替代优势突出

近年来，以GreatSQL、PolarDB-X、StoneDB、TenDBCluster-TenDB、AliSQL等为代表的国内开源数据库已初步构建多方参与的开源社区生态。各社区在应用落地、社区活跃、代码贡献等层面围绕自身特点不断完善，积极探索国内开源数据库社区未来生态发展方向。

其中，GreatSQL社区的生态建设成果较为突出。GreatSQL开源数据库有着较为丰富的应用案例与行业应用场景落地数量，在代码贡献、活跃度、更新频率、技术创新等方面表现亮眼，社区活力持续提升。

01 代码贡献层面

GreatSQL社区贡献者构成多元化并逐年稳定增长，同时社区问题互动与拉取请求十分活跃；

02 活跃度方面

GreatSQL数据库社区活跃度较高，社区响应能力突出，针对社区问题与PR等反馈及时，持续提升社区活力；

03 更新频率方面

GreatSQL数据库社区更新频率较高，不断完善自身社区与产品建设，更好地满足不同业务场景需求；

04 技术创新方面

GreatSQL针对MGR进行了大量深入的源码级优化，新增地理标签、仲裁节点、读写节点可绑定动态VIP、智能选主、快速单主模式等多个企业级实用特性，修复大量严重故障场景下的稳定性和可靠性问题，可适用于金融级应用；

05 性能优化方面

作为OLTP数据库，GreatSQL在内核事务吞吐性能方面做了大量优化，能同时满足企业事务处理（OLTP）与分析处理（OLAP）需求。在OLTP性能上做了大量的锁拆解和无锁化优化改造，OLAP方面从并行执行角度针对每⼀个InnoDB子树进行优化。TPC-H场景中，优化后的GreatSQL在查询效率方面可提升最高40倍性能；

06 安全性方面

GreatSQL数据库新增表空间国密算法支持功能，进⼀步增强数据库安全性。在开源MySQL原有keyring架构上，通过国密算法增强架构安全性，从而提升数据库整体安全性。

国内开源数据库产业展望

最后，针对我国MySQL技术路线开源数据库产业发展，报告进行以下展望：

1 开源数据库发展应符合开源生态建设及产业引领要求，积极参与完善开源产业治理；

2 加强相关方对开源协议认知，合法合规利用开源协议；

3 利用国内MySQL现有技术生态，结合产业需求，加强独立演进开源分支的能力；

4 大力推进开源数据库技术规范化、智能化发展。

三、GreatSQL调研

据悉，GreatSQL开源社区的初衷是将其打造成【中国的MariaDB】，即中国的MySQL技术路线自主开源数据库。选择Percona作为基础，是因为他们希望在已经优化了MySQL官方社区版的基础上进一步提升GreatSQL的性能。除了Percona Server已有的稳定性、高效性和更便捷的管理等优点外，GreatSQL还针对MGR进行了大量深入的源码级优化，新增诸如地理标签、仲裁节点、读写节点可绑定动态VIP、智能选主、快速单主模式等多个企业级实用特性；同时修复大量严重故障场景下的稳定性和可靠性问题，并对性能吞吐、稳定性、安全性进行了大幅提升，可适用于金融级应用。

GreatSQL至今已经发布了5个开源版本，包括兼容5.7和8.0的。社区保持每半年发布一个版本的开发节奏，这在开源社区中也属于更新频率非常高的，可见社区的活跃度高。

GreatSQL是由万里数据库维护的MySQL技术路线国内开源分支，它与MySQL和Percona Server完全兼容，完美继承了MySQL在国内的技术生态，包括周边工具，可作为它们的替代选择，用于线上生产环境。更重要的是，GreatSQL完全免费。

greatsql特性

官方手册介绍：

GreatSQL具备高性能、高可靠、高易用性、高安全等多个核心特性。

1. 高性能

• 支持InnoDB并行查询，适用于轻量级OLAP应用场景，在TPC-H测试中平均提升15倍，最高提升40+倍。
• 优化InnoDB事务系统，实现了大锁拆分及无锁化等多种优化方案，OLTP场景整体性能提升约20%。
• 支持并行load data，适用于频繁导入大批量数据的应用场景，性能可提升约20+倍。
• 支持线程池（thread pool），降低了线程创建和销毁的代价，保证高并发下，性能稳定不会明显衰退。

2. 高可靠 GreatSQL针对MGR进行了大量改进和提升工作，进一步提升MGR的高可靠等级。

• 地理标签，提升多机房架构数据可靠性。
• 读写节点动态VIP，高可用切换更便捷。
• 仲裁节点，用更低的服务器成本实现更高可用。
• 快速单主模式，在单主模式下更快，性能更高。
• 智能选主，高可用切换选主机制更合理。
• 全新流控算法，使得事务更平稳，避免剧烈抖动。
• 优化了节点加入、退出时可能导致性能剧烈抖动的问题。
• 解决磁盘空间爆满时导致MGR集群阻塞的问题。
• 解决了长事务造成无法选主的问题。
• 优化事务认证队列清理算法，规避每60s抖动问题。
• 修复了recover过程中长时间等待的问题。

3. 高易用性 支持多个SQL兼容特性，包括CLOB、VARCHAR2数据类型，DATETIME运算、ROWNUM、子查询无别名、EXPLAIN PLAN FOR等语法，以及ADD_MONTHS()、CAST()、DECODE()等17个函数。

更多信息详见文档：GreatSQL中的SQL兼容性 (opens new window)。

4. 高安全性 支持逻辑备份加密、CLONE备份加密、审计日志入表、表空间国密加密等多个安全提升特性，进一步保障业务数据安全，更适用于金融级应用场景。

更多信息详见文档：GreatSQL中的安全性提升

下面是GreatSQL 和 MySQL社区版本的对比表格：

叶金荣将 GreatSQL 全新的 8.0.25-16 版本与 MySQL 8.0.25 的社区版本进行对比，详细介绍了新版本的特点以及优化升级的内容。此次 8.0.25-16 版本更新后，GreatSQL 的性能、稳定性都得到了大幅提升。

​ ▲GreatSQL8.0.25-16 版本与 MySQL 8.0.25 社区版本对比

greatsql具体的优势特性

1、地理标签

首先为大家介绍GreatSQL 地理标签的功能，这个新功能主要用于解决多机房数据同步的问题。

新增选项 group_replication_zone_id，用于标记节点地理标签。该选项值支持范围 0 ~ 8，默认值为0。当集群中各节点该选项值设置为不同的时候，就被认定为设置了不同的地理标签。在同城多机房部署方案中，同一个机房的节点可以设置相同的数值，另一个机房里的节点设置另一个不同的数值，这样在事务提交时会要求每组 group_replication_zone_id 中至少有个节点确认事务，然后才能继续处理下一个事务。这就可以确保每个机房的某个节点里，总有最新的事务，从而保证数据不会丢失。

2、仲裁节点

在GreatSQL 8.0.25-16版本中，新增MGR Arbitrator节点（仲裁节点）角色。 该节点只参与MGR投票仲裁，不存放实际数据，也无需执行DML操作，因此可以用一般配置级别的服务器，在保证MGR可靠性的同时还能降低服务器成本。

3、快速单主

第三个优势特性是新增快速单主模式，在这个模式下，不再采用MySQL MGR原有的认证数据库方式。新增选项group_replication_single_primary_fast_mode用于设置是否启用，以及具体采用哪种模式。 快速单主模式特别适合在跨机房部署，压力测试以及内存要求不高等多种场景。这种模式弱于传统的异步复制，但强于半同步复制，且没有MGR默认的认证数据库可能消耗较大内存的问题。

4、智能选主/自定义选主策略

智能选主、自定义选主策略是GreatSQL 新版本的又一优势特性。原来的选主策略中没有判断各节点最新事务状态，可能会导致丢失部分事务数据。

在GreatSQL中，新增选项 group_replication_primary_election_mode 用于自定义选主策略，可选值有以下几个：

• WEIGHT_ONLY，还是按照上述传统模式自动选主，这是默认值。
• GTID_FIRST，优先判断各节点事务应用状态，自动选择拥有最新事务的节点作为新的主节点。
• WEIGHT_FIRST，传统模式优先，如果没有合适的结果再判断各节点事务状态。推荐设置为该模式。

5、并行查询

最后要给介绍的是并行查询，这也是我认为最重要的一个特性。

在并行查询中，对B+树多个子树并行扫描后再聚合，大大提升查询效率。在TPC-H测试中，最高可提升30倍，平均提升15倍。并行查询的功能特别适合汇总报表之类的SAP、财务统计等业务。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

下方InnoDB并行查询性能提升的效果展示，提升3.491倍-32.823倍不等。

用户案例：

另外，greatsql开辟了迁移升级模块，提供了mysql迁移、升级到greatsql的过程