大家好，我是考100分的小小码 ，祝大家学习进步，加薪顺利呀。今天说一说观点 | 用 MySQL 数据库，到底会不会被“卡脖子”？[通俗易懂],希望您对编程的造诣更进一步.
导读 作者简介： merming，多年数据存储、云计算系统运维和技术支持经验，目前从事 MySQL 数据库方案设计工作，曾为众多制造业、金融、电信行业用户提供 IaaS 及 PaaS 建设方案。 本文转载自公众号：知数堂
用 MySQL 数据库，到底会不会被“卡脖子”？
在近期不明朗的贸易形势下，一些正在规划数据库选型、迁移的用户，纷纷询问我们对 MySQL 未来前景的看法。那么使用 MySQL 数据库会出现被“卡脖子”的情况吗？
下面我将从中美当前的一些文件条例以及数据库技术架构本身的角度为大家进行解答。
商业风险（美方角度）：
Oracle 公司的数据库产品中，多数产品受美国出口管控条例（Export Administration Regulations，EAR）管控，Oracle 官方已在今年 8 月更新了其产品对应的出口管控类别编码（Export Control Classification Number，ECCN，这里关于 ECCN 的背景和分类我们不展开描述）。
其中，对于 Oracle 数据库产品线（Oracle 10g 以及以上版本）以及其他配套软件工具均在 5D992.C 类别中。对于 MySQL 产品线，MySQL 企业版、MySQL 标准版、MySQL 经典版、MySQL 集群版以及 MySQL 嵌入式版同样在 5D992.C 类别中，然而，在 Oracle 提供的表单中，并没有 MySQL 社区版（MySQL Community Edition）的记录。
![观点 | 用 MySQL 数据库，到底会不会被“卡脖子”？[通俗易懂]](https://www.yht7.comhttps://www.yht7.comhttps://www.yht7.comhttps://www.yht7.comhttps://www.yht7.com/upload/image/20191112/1240.png "观点 | 用 MySQL 数据库，到底会不会被“卡脖子”？[通俗易懂]插图")
![观点 | 用 MySQL 数据库，到底会不会被“卡脖子”？[通俗易懂]](/wp-content/themes/justnews/themer/assets/images/lazy.png "观点 | 用 MySQL 数据库，到底会不会被“卡脖子”？[通俗易懂]插图1")
http://www.oracle.com/us/products/export/eccn-matrix-345817.html
由此可见，MySQL 社区版作为开源软件，在 EAR 条例的政策中，有别于 MySQL 企业版等商业软件。下面是 MySQL 官网关于各 MySQL 版本的介绍，这里我们不展开描述。
这个时候问题来了，MySQL 项目以及整个开源生态发展到今天，其中关系早已是，你中有我，我中有你，MySQL 中就包含大量第三方组件，这些组件有些作为功能合入了主版本，如我们今天使用的半同步复制源于 Google；而有些组件则作为软件包合入并保留了原有 license，如 innodb 默认使用的异步调用包 libaio。那么如果这些组件受到 EAR 管控怎么办？这时候 MySQL 社区版是否还能和 EAR “划清界限”？
由于 MySQL 中涉及的第三方软件太多并且存在持续增加的可能，关于这点我们不能完全给出肯定，但是，我们特别查找了关于出口加密软件源码在 EAR(734.17) 中的描述。由于加密软件与通信安全相关，其管控力度有别于普通软件，在一定程度上可作为边界进行对比参考。（这里关于加密软件为何特殊的缘由我们不展开描述）。
首先，在满足 EAR(742.15(b)) 要求的前提下，面向公众开放的加密软件源代码不受管控。
接下是 EAR-742.15 的具体内容：
对于加密类软件，首先需要遵守加密软件出口 license 条例，其次，每项出口均需要经过二次审查。而对于加密软件源码，面向公众开放的加密软件源码，不在 EAR 管控范围内（当然，这并不意味着它不受美国其它法律条例限制，此处我们不展开描述），但是，使用、修改、发布这些源码时，需要向美国商务部相关单位（BIS 和 ENC Encryption Request Coordinator）进行邮件报备。
结合两方信息，我们在 Oracle 给出的 ECCN 编码中没有发现 MySQL 社区版，同时 MySQL 所包含的含加密功能的软件（如 OpenSSL Kerberos）满足面向公众开放源码的要求。因此，除非 EAR 内容大幅度修改，否则使用 MySQL 社区版，目前不存在EAR管控方面的风险。（这里可能有同学会提出疑问，关于 MySQL 是否会被闭源，这次我们不进行阐述）。
商业风险（中方角度）：
阐述完美方的文件条例，下面我们对国内的趋势性文件做一个简单的说明。2017 年，工业和信息化部和国家发展改革委两部委正式印发了《信息产业发展指南》，文件中提出**“支持开源、开放的开发模式，重点推进云操作系统、云中间件、新型数据库管理系统”。**
http://www.miit.gov.cn/n1146295/n1652858/n1652930/n3757016/c5464809/content.html
这表示，开源模式在基础软件的发展中已得到认可，近几年 MySQL 在中大型终端用户群体中，除了应用的规模外，应用的深度也在不断发展，越来越多的非互联网行业用户开始走开源 + 自主管理的整体发展模式，这也使 MySQL 数据库的生态环境不断丰富成熟，因此，从近几年金融、电信等行业的建设成果看，使用 MySQL 并不存在政策风险。
综上所述，当前环境下，不论从中方或是美方政策视角出发，选择 MySQL 社区版数据库，不会存在商业上的风险。
技术可行性（ RTO/RPO 可用性级别）：
最后，从技术架构角度，以 Oracle RAC 为代表的商业数据库高可用，通常与存储设备一同部署，由中高端双（多）控制器磁盘阵列充当数据的保险箱，因此 RAC 架构是将数据库的风险转移到存储设备，增强了系统故障中的短板（磁盘），本质上是提升了单点抵抗故障的能力，但局部单点故障仍存在。
而 MySQL 高可用架构，如主从复制/组复制，则采用一主多从模式，将一份数据保留到多个位置（银行业通常采用本地 1 主 1 从 + 同城 2 从的共 4 个库组成数据库高可用组），本质上是利用数据冗余换取更高概率的数据安全，做到避免单点故障。（关于主从复制与组复制和 Oracle RAC 的对比我们不展开讨论）。
因此，在架构得当、运维规范的前提下，MySQL 的高可用机制也能提供金融级的保障能力，同时，对于以上高可用功能，MySQL 社区版与 MySQL 企业版完全一致，能够在不被“卡脖子”的前提下，满足业务对数据库的可靠性要求。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
转载请注明出处: https://daima100.com/11041.html
