什么是“停服”？
这里的停服，不是服务器“停了、挂了”，而是指产品生命周期终止（EOL），从此，这个产品将完全停止支持和维护。
具体到MySQL5.7，是指这个版本，从10月21号以后不管出了什么问题，都不会再有来自社区官方的补丁升级了。
不仅功能性的bug没人修，更严重的是，安全漏洞也不会有人管。
有人说，受影响的不就是一个版本吗？MySQL 3.x、4.x、5.0/5.1/5.5/5.6停服的时候，也没见你们这么叫唤啊
只因，MySQL5.7真的不一样！
首先，这些年来，MySQL始终都是流行度最高的数据库之一，更是市场占有率最高的数据库，达到不可思议的43.4%。
而在这么高的流行度和市占率背景下，有小一半（46.7%）的现网MySQL服务器，竟然都是5.7版本！
所以你知道问题的严重性了吧，也就是说，这次“停服”，市面上五分之一的数据库都可能受到影响。（43.4%×46.7%=20.3%）
虽然MySQL的后台老板“O记”站出来说，商业付费版的MySQL他负责兜底，但对于更多使用免费社区版MySQL用户来讲，就真的欲哭无泪了。
尤其对于广大客户来说，无论付费免费，数据库都承载最重要的数据、最核心的生产业务，万万不能出问题。
那么，针对这件事，国内各大重点行业是怎么看的呢？
中国信通院旗下的云计算开源产业联盟，最近发布了一份《开源数据库生态发展研究报告——MySQL开源数据库》，包含了大量重点行业客户的调研数据。
我们看看，头部客户面对“停服”的应对思路。
▌金融行业
作为数字化的排头兵，金融行业是数据库的重度使用场景。开源数据库应用范围极广，办公管理系统、工具类系统、财务投资系统、经营分析系统等等场景都在深度使用。
根据调研，具体使用比例如下↓
80%的受访金融企业，认为MySQL开源版本能够降低企业使用成本，这也成为他们选择MySQL开源版本的主要原因之一。
当然，金融客户对MySQL也有不少吐槽，比如性能瓶颈、安全漏洞、商业闭源等问题。
其中安全漏洞和缺陷是广大企业最担心的问题，这需要专门团队进行运维，而其官方社区的“闭源”风险也在制约企业进一步使用。
再回到我们最关注的“5.7停服”问题↓
在所有部署了MySQL的金融企业中，近六成企业选择了MySQL5.7版本作为其运行版本，其中更有近三成企业5.7版本占其部署总比例的80%以上。
怎么样，隐患的比例是不是很高？！
面对如此大的部署比例和如此紧迫的时间线，金融客户如何应对呢？
据报告调研，在⾦融⾏业中，71%的企业已经知晓MySQL5.7版本“停服”事件，其中大部分企业（88% of 71%）已经做出了应对⽅案。
所有应对方案里，约三分之一企业将迁移到MySQL8.0版本，约十分之一的企业选择躺平。
而更多的企业（超过五成），希望迁移到国内数据库。
当然，替换也不是一蹴而就的事，金融企业在替换MySQL5.7时，迁移难度和改造成本是首要考虑因素。
另外，可靠性、可用性、可服务性，以及安全性、兼容性、性能都需要权衡。
而且，银保监会等主管部门的政策要求也会影响选型（比如XC和国产化）。
看完最严苛的金融行业，我们再来速读一下电信和能源这两个头部行业的情况。
▌电信行业&能源行业
MySQL开源数据库在电信行业的CRM系统、渠道管理系统等核心业务场景应用广泛。
电信企业分省子公司部署MySQL数据库普遍在100-200套，有些省份甚至超过500套。而且，大部分企业选择5.7版作为运行版本，总部署量超过一半。
但因为省分公司数据库运维能力相对不足，部分电信类企业存在对MySQL5.7版本“停服”事件不知情的情况。
而在应对措施方面，主要选择迁移到MySQL8.0或者暂时按兵不动。
能源行业作为开源数据库新兴应用领域，占比较低，⼤部分企业MySQL开源数据库部署数量不超过总量的50%，且MySQL5.7版本使用比例不高（低于30%）。
不过，能源行业对MySQL5.7“停服”事件有较强认知，且大部分企业在应对方案选择上，倾向于迁移到国内开源数据库。
谈到数据库的迁移与替换的关注点，电信和能源行业同样把迁移难度、改造成本作为最重要因素。
综合一下三个头部行业的调研结果，我们不难发现：
❶ MySQL5.7的普及率确实很高，即便是“不差钱儿”的能源行业，也有近30%的安装量，金融和电信就更加夸张了。
❷ 在应对策略上，各行业虽然略有差异，但迁移到国内数据库基本是众望所归。
❸ 在对国内数据库迁移的考量上，迁移难度、改造成本都是最主要的关注点。
问题很严重，时间很紧迫，要怎么迁移才是最平滑的方案？
其实，从平滑的角度看，迁移到与MySQL相同基因的数据库，自然是风险最小的。
国内有不少基于MySQL技术路线的开源社区，这份报告从五个维度、九个指标进行了横向比较。
国内比较活跃的“MySQL系”开源数据库社区，主要有GreatSQL、PolarDB-X、StoneDB、TenDB和AliSQL，其中不少是互联网巨头发起的。
但因为战略的不断调整，以及内部多套数据库的“内卷”，导致巨头发起的开源社区表现相对乏力。
反而是后起之秀的GreatSQL社区，苦心经营，一步步发展壮大，脱颖而出，成为综合表现最好的那个↓
所以，我们就来简单聊聊，如果用GreatSQL来作为MySQL的替代方案，究竟可不可行？
第一，看社区，这是一个开源数据库未来可持续性的基础保障。
前面的横评已经证明了这一点，GreatSQL开源社区在代码贡献、活跃度、更新频率、技术创新等方面表现亮眼，这是GreatSQL数据库强大的基本盘。
第二，看产品功能硬核PK，毕竟社区再活跃，产品不能打也白搭。
从GreatSQL与MySQL的开源版本点对点比较来看，GreatSQL表现相当优秀。
甚至在SQL兼容扩展、MGR提升、性能、安全性这四个方面，GreatSQL都取得了完胜。
GreatSQL完全免费并兼容MySQL，广大行业客户所纠结的迁移难度、改造成本等问题，全部可以迎刃而解。
对于正在使用MySQL5.7版本客户，可以完全平滑、免费过渡到GreatSQL5.7、GreatSQL8.0，从而获得持续支持，规避“停服”风险。
更重要的是，在兼容性之外，GreatSQL比MySQL提供更好的性能、可靠、易用性、安全性，以及满足合规要求。
第三，看成功案例，那些使用GreatSQL的场景，用得怎么样？
目前GreatSQL已经广泛应用于金融、互联网、IT软件、企业等场景，我们来看一个银行客户非常有代表性的场景。
梅州客商银行采用GreatSQL打造了主备数据库方案，不仅支撑起征信指标平台、数据安全平台等多个业务系统，还完美实现了全栈XC适配。
最后，简单说说我们的结论↓
GreatSQL完全免费且100%兼容MySQL，支持无缝迁移、平滑过渡，还能提供更优秀的体验（高性能、高可靠、高安全、高易用），以及来自社区可信赖的长期支持与维护。
特别预告：GreatSQL社区即将在11月初上线「MySQL5.7停服解决方案专区」，如有迁移替换需求，敬请关注！
MySQL5.7“停服”在即，GreatSQL“接棒”大势所趋~
