经过三篇文章的讲解，终于到了水落石出的时候。最终答案，已经呼之欲出。
前三集的链接：
国产数据库，这波热潮始于特朗普，他在任期内，发起对中国的全面对抗，刺激中国开启全面的国产化替代，开始了国产数据库热潮。
可惜，在2020年后，这位对中国数据库事业，做出巨大贡献的国际友人，没有连任成功。
真是"待到山花烂漫时，他在丛中笑"。
但在特朗普还忙于搞地产时，2009、2010年开始，阿里巴巴就率先启动了Oracle替换项目。这个项目最终演变为轰轰烈烈的去IOE运动，甚至上了央视新闻。
到2011年，阿里巴巴最繁忙的网站之一：中文站，就全面完成去O的大动作。
我作为当时阿里巴巴B2B 数据库团队级别最高的技术人员，全程参于了这场多部门协作、历时一年多的大项目。我们用“后世“被称为“分库分表“的方式（当时还没这种叫法），把Oracle的数据，分散到多个MySQL中。而且，顺便的把IBM的小机，也换成了普通的PC Server。EMC这种高端的存储设备，也跟着被替换。
整个项目的难度，就像为一架飞行中的空客A380替换发动机。现在想想，这个项目的成功有偶然性，也有必然性。
在2008年，Intel发布了Nehalem微架构的CPU。
经过几十年的追赶，Nehalem的技术已经和IBM的Power CPU大同小异。超标量、乱序执行等等已经和Power完全一样，甚至超过。IBM的小机，其实只剩一个优势，稳定。
而数据库在软件层面，可以解决稳定这个问题，无非就是数据多几份冗余。
还有使用PCI-E接口的SSD闪存卡，也在2008、2009年变的成熟，而且价格也为较平民了（相较于高端存储设备）。
硬件技术发展到2009的时间点，去I、E，已经毫无压力。
至于去O，也不成问题。
阿里巴巴中文站流量很大，是真正的海量数据、超高并发。但应用程序，主要SQL却都较为简单。
这很容易理解，阿里巴巴中文站就像一个超大规模的商场，主要业务，就是买、卖，只是人流量超大。而真正的难点，就是人流量超大带来的
“海量数据、超高并发“，但分布式解决了这两个问题。因此，在对应用历时一年多的分布式改造后，去O毫无悬念的成功了。
说好的卡脖子呢？原来十多年前我们就能去O了，怎么不卡了。
其实，这其中另有隐情。咱们接着往下聊。
随后几年，去IOE愈演愈烈，从阿里传导到社会。但阿里巴巴内，一直有套系统，还在使用Oracle。
这套系统数据并不海量，也没有超高并发，也就是用于公司内部管理，它叫PeopleSoft。
PeopleSoft，我是外行，我甚至不知道它准确的定位。财务管理、ERP还是CRM ……，不清楚。只知道，它就是我们上一篇文章，末尾提到的，大型商业管理系统。
我和PeopleSoft的接触，主要是发工资。集团发工资偶有延迟，传说因为工资是一个复杂的系统计算的（就是PeopleSoft），计算规则十分复杂，财务人员都是在发薪日的前几天，早早开始计算任务，有时甚至长达三、四天，PeopleSoft才能完成所有人员工资的计算。
阿里也不过十万人规模，什么样的SQL，十万人规模的数据量，跑三、四天还跑不完？
后面有几次，工资计算险些超过发薪日。对于阿里这样规模的公司，如果延迟发放薪水，各种流言蜚语的影响下，不知道会引发什怎样的事端。
要知道阿里巴巴各个站点，什么中文站、国际站等，那个用户数不是过亿、数据量不是百亿规模。SQL在毫秒量级完成是基本要求。这十万人规模的系统，怎会如此慢？
专门提这一点，是希望大家了解大型商业管理和互联网应用并不相同。
继续说回这套PeopleSoft，后面我们数据库团队，责无旁贷的接手了对这套系统的优化。PeopleSoft生成的SQL的确恐怖，复杂无比，这是它慢的主要原因。
优化之后，在数小时内算完集团所有员工的薪水，已经最快的性能了。
这个优化项目后，我得到了PeopleSoft底层数据库的密码。后来经过层层追踪，终于找到了记录每个人级别、股票期权、工资收入等信息的表。在感叹PeopleSoft复杂度的同时，我第一时间执行了条SQL，查找马云老师的工资、期权等收入，……。
这后面不能讲了，先买个关子。还是回到正题。
打个比方，阿里巴巴中文站，海量数据、超高并发，相当于一个超大规模商超，业务简单，买、卖为主。
PeopleSoft这种大型管理系统，相当于一个证券交易所，比人流量、并发量，比不上大型商超的零头。但证券交易所业务的复杂度，可是深不见底。
现在，关于以下这个问题，你有答案了吗：
“为什么阿里巴巴在2012年前后就已经完成了去O，在2018年，国家还是把数据库列为卡脖子技术？“
是因为大型商业管理系统吗？
国内也有啊，我们的国货之光，华为不是还有Meta ERP吗？
别急，这篇太长了，下篇，答案揭晓。
