为什么互联公司都用MySQL非oracle，难道只是便宜

    在itpub论坛上看到VAGE对这个问题的论述，非常精彩，忍不住转一下。

第一段：

当数据量太大、并发太高时，有两种解决方案：

1、仍然使用集中式方案，提升单台主机的能力。
2、使用分布式方案。

两种方式都可以解决问题，就看高层如何选择了。阿里选择了分布式。
一旦选择了分布式，比如将一个大表分到多个数据库中。如果是Oracle，数据库太多license费用随之上升。如果是MySQL，数据库再多也不用担心License问题。所以，MySQL胜出。
而Hadoop类的纯分布式方案，在OLTP下，优势并不明显。它们是为大数据而生的。

如果选择了集中式，照样有方法解决。因为世界上并不只有BAT，并非Oracle搞不定高并发、大数据量的OLTP系统，就看硬件、和人的投入了。

阿里只所以没有选择集中式，主要是其他团队想上位，他们为高层描绘一个美好的明天。
你没看到阿里的这一轮去O风潮，阿里系老一代DBA都失去主导权了吗。技术圈里很少再有他们的声音。这就是政治，说白点就是江湖。有人的地方就有江湖。阿里系老一代DBA中不乏有拿着千万的股票提前退休的，退出江湖，衣锦还乡，不错啊。

分表、分库后，面临两个问题：
1、要有强大的中间层。阿里在这一块的投入是巨大的。这直接催生了另一派势力。
2、分表、分库后，跨库事务成为问题。这一块至今都没有好的方案解决。

至于互联网业务的发展，当然不会被Oracle限制。到是上面所说的分表的方案，限制了一部分应用。如果当初选择的是集中式方案，应该不会有这方面的限制。

第二段：

源码修改，阿里所造的较大的修改，据了解只有仿照一个日本人的方式，去掉了MySQL的解析过程。
修改过的MySQL的应用范围，不太清楚。阿里的重心也不在这一块，对源码，要了解。
了解源码的目的是为了更深的了解MySQL的优、缺点，更好的使用MySQL。还有，可以基于MySQL开发一些产品。

这其实是使用开源产品的两大优势：
1、可以更加了解软件运作的原理，更好的设置MySQL。一旦出了故障也可以准确定位。
2、可以更容易开发周边产品。比如开发解析Oracle Redo的产品极为困难，但MySQL就不一样了，Redo的格式是公开的。

Oracle现在是越来越封闭，在不使用调试技术的情况下，研究Oracle日渐艰难。许多性能资料、等待事件的本意无从知晓，问题的定位比较困难。开源的MySQL不存在这样的问题。

国内互联网巨头多在开发基于MySQL网络协议的代理层。简单点说你连接MySQL，其实是连接了代理层，由代理层把你的SQL发到某个MySQL库中执行，如果是OLAP型SQL，由代理层用协调器，将SQL分布到多个MySQL库中执行，再由代理层合并结果。
如果下层是Oracle，这样的代理层开发极为困难，因为要全面了解网络协议。如果是MySQL则不同了。

第三段：

OLAP、大数据领域，分布式优势明显，Oracle、MySQL这些为集中式设计的数据库劣势明显。
但在OLTP领域，纯分布式（比如Hadoop）方案并无优势。

用MySQL做分布，要有一个代理层（或中间层），程序连接这个代理层，程序以为连接的是一个MySQL，但实际是背后是一堆MySQL。
这样的分布式方案，在跨库事务这一块上是弱点，有可能限制了业务发展。
纯集中式方案不存在这样的问题。

分布式在OLTP中也要用，但对于OLTP来说，不到万不得一，不要分布。能分两台、不要分三台。
OLAP简单的堆机器、拼机器数量没问题，OLTP下机器数量一旦失控，其产生的问题、成本等等更难以控制。

现在硬件都在提升。SSD、InfiniBand更快的网络等等技术，使用RAC这样的有限式分布方案，基本上都可以满足OLTP的需要。

而MySQL由于开源，可以带来两大优势：
1、可以更加了解软件运作的原理，更好的设置MySQL。一旦出了故障也可以准确定位。
2、可以更容易开发周边产品。比如开发解析Oracle Redo的产品极为困难，但MySQL就不一样了，Redo的格式是公开的。

Oracle现在是越来越封闭，在不使用调试技术的情况下，研究Oracle日渐艰难。许多性能资料、等待事件的本意无从知晓，问题的定位比较困难。开源的MySQL不存在这样的问题。

国内互联网巨头多在开发基于MySQL网络协议的代理层。简单点说你连接MySQL，其实是连接了代理层，由代理层把你的SQL发到某个MySQL库中执行，如果是OLAP型SQL，由代理层用协调器，将SQL分布到多个MySQL库中执行，再由代理层合并结果。
如果下层是Oracle，这样的代理层开发极为困难，因为要全面了解网络协议。如果是MySQL则不同了。

转载自：http://www.itpub.net/thread-1843640-1-1.html