尽管Facebook使用MySQL，但它们并不是一成不变的使用它。 事实上，他们的团队已经提交了许多MySQL核心和Innodb插件的高性能增强。 他们的主要重点是增加性能计数器到Innodb。 其他更改集中在IO子系统上，包括以下新功能：

1 innodb_io_capacity：设置服务器的IO容量以确定后台IO的速率限制

2 innodb_read_io_threads, innodb_write_io_threads：设置后台IO线程

3 innodb_max_merged_io：设置可能合并到一个大IO请求中的相邻IO请求的最大数量

Facebook使用MySQL作为键值存储，其中数据随机分布在一大组逻辑实例中。 这些逻辑实例分散在物理节点之间，负载均衡在物理节点级完成。 Facebook已经开发了一个分区方案，其中全局ID被分配给所有的用户数据。 他们也有一个自定义的归档方案，它基于每个用户的频繁和最近的数据。 大部分数据是随机分布的。 令人惊讶的是，据传Facebook有1800个MySQL服务器，但只有3个全职DBA

Facebook主要将MySQL用于结构化数据存储，例如墙贴，用户信息等。这些数据在各个数据中心之间复制。 对于blob存储（照片，视频等），Facebook使用一个自定义的解决方案，涉及外部的CDN和内部的NFS

同样重要的是，Facebook大量使用Memcache，这是一种内存缓存系统，通过在RAM中缓存数据和对象来加速动态数据库驱动的网站，以减少阅读时间。 Memcache是Facebook的主要缓存形式，大大减少了数据库的负载。 拥有一个缓存系统可以使Facebook的速度与调用数据一样快。 如果不需要访问数据库，则只需根据用户标识从缓存中获取数据

所以，“Facebook使用什么数据库”似乎是一个简单的问题，你可以看到他们已经添加了各种其他系统，使其真正的具有网络可扩展性。 但是，仍然可以自由地使用这样一个观点：“MySQL和Oracle或者MS SQL Server一样好或者更好，因为就算只有Facebook使用它，它也有5亿用户！”

谢邀。我分享下他们MySQL运维优化的逻辑，大家可以借鉴参考一下。本质上讲，他们用的是修改后的MySQL，不是原生MySQL。Facebook创办以来就一直在使用MySQL数据库，也随着数据量的增大而不断改进他们的自有MySQL，目前已经可以轻松支撑来自20多亿用户的数据量。

所以Facebook优化MySQL的经验我觉得有很多借鉴学习之处，有相关数据库经验也可以在评论区讨论探讨，互相学习学习。

1.每台机器都使用多实例的模型，每个机器放多个实例，每个实例放多个DB，多实例之间没有资源隔离，充分发挥实例间的最大性能。

2.将大部分核心业务引擎切换到MyRocks，不改变服务器配置大概可以节省一半服务器资源。

3.主从结构采用基于GTID的一主多从结构，外加一个基于lossless semi-sync机制的mysqlbinlog实现的binlog server。

4.所有的备份都是基于mysqldump实现，可以无需备份索引，只备份数据，而且备份文件压缩比高，更节省磁盘空间，通过改进了的mysqldump，备份过程中还可以进行额外压缩。当然备份时也会控制并行备份的数量，避免影响在线业务性能。

5.快速部署从库可使用xtrabackup在现有存活的SLAVE实例上备份，也可在主库上发起备份，再利用WDT（或者是BT）协议传输到异地，用于拉起从库。

总而言之，Facebook在优化MySQL方面做了很多努力，也提交了很多优秀的Innodb插件来大大提高了MySQL主从集群的性能。而且有传闻称，Facebook拥有大约1800台MySQL服务器，内部却只有三名数据库管理员（DBA）。这有点匪夷所思，不过也侧面说明Facebook确实在MySQL优化方面有着非常不错的效果。

如果你对学习人工智能和科技新闻感兴趣，欢迎订阅我的头条号。我会在这里发布所有与科技、科学以及机器学习有关的有趣文章。偶尔也回答有趣的问题，有问题可随时在评论区回复和讨论，看到即回。

（码字不易，若文章对你帮助可点赞支持~）

看了这么多回答，作为一个当时参与ucloud去lOE过程的人，聊聊个人看法。

ucloud在定下2014目标上市时，内部就开始发起去IOE运动，2013年收尾。全球上市意味着要经过全球检验，要合法合规（至少大面上要这样）。首要过的，就是专利（如现在高通，每部用它专利的手机都得给它交钱）。随ucloud商业化程度的进行，马云就放眼全球。当时核心诉求是，可控性（不能将自己的咽喉放在别人的手上）。记得我当时还问过为什么会发起这么大成本的去IOE化，得到的回答是IOE不可控（比如orocle，发生一个问题可能几天之后才得到响应，对于快速发展的互联网来说，是不可接受的）。从互联网商业角度来讲，钱不是关键的，时间、流量才是王者。互联网服务要求稳定、快速解决大于一切。这也是现在分布式的核心诉求（大数据也是）。能用钱解决的问题都不是问题，比如互联网企业前期大部分是巨额亏损的（如BAT，滴滴，共享单车…），它们要的是快速占领市场。在此前题下，lOE，有两大致命伤：

1，出问题后解决的效率太低（lOE作为稳定性产品，更新节奏是比较慢的，并且因为不开源，意味着它是黑箱，遇到问题你连找临时解决的方案都很难，等到厂商问题解决，黄花菜都凉了），

2，不可控。互联网是快速试错的过程，今天稳定的东西可能明天就满足不了需求了。指望厂商跟进，就会错过大量的时机（这也是现在大数据技术快速发展和各大互联网企业投入巨大资源自研的原因）。数据库作为互联网核心部件（数据就是金钱），命脉必须掌握在自己手里。开源推进了现代互联网的快速发展，技术不再是少数企业的专利，开源能集结全球人才的聪明才智，能够快速解决问题，而不是局限于等待少数人去改变。开源意味着可预测，可控制、可把它作为基础发展为最适合自身业务的东西。

其它：1，免费，降低成本。2，可研究，人才众多。3，实时大数据，批量。

现在各大互联网公司已根据自身业务特点，已经在开源基础上研发了大量的定制数据库。

从创业起步时角度来讲，确实能省一些是一些，MySQL够用了。发展大了之后，做分布式集群话，稳定度和速度、灵活性都大大大于lOE，lOE也就没那么必要了。4，去lOE还能大幅度培养自己的技术团队，拓展未来的想象力，何乐而不为。

反之，看先前和现在的国有企业（如银行），动不动就停机维护，以前转个帐都要24小时甚至更长（因为它们是垄断，它们不缺钱，一体化都是最高端的lOE服务，所以我们无可奈何）

，这种情况若发生在互联网身上，那可能就是生死攸关的事情——用户的敏感度大大大于传统的企业。

从上情况可知，选择去lOE是必然，甚至，互联网企业发展到一定规模，自研是必然（自研当然需要建立在合法合规上）。

企业发展到一定程度，有3个最重要的：1，企业架构（自动化机器）2，法律风险（投入比会大大增加，比如现在ucloud遇到的情况）3，门槛（核心技术，核心竞争力）

个人浅见，共同交流。

Facebook最初诞生的时候并不是大公司，所以整个数据底层都是放在MY SQL上，因为MY SQL不需要授权费，对facebook是最划算的，而在发展壮大后，MY SQL同样够用，当然会一直用下去了。

为什么Facebook还会用MY SQL?

1.MySQL早期就是为PC互联网服务的，而且是免费开源的，Facebook早期是学生创业，跟本没钱，而且Facebook最开始是PC产品，用MY SQL是自然的。

2.用MY SQL更省钱。除了MY SQL还有商业数据，比如Oracle数据库，但是商用数据库价格非常的贵，比如官方报价一般25/CPU核，以及采购小型机一般80-120万/台，存储设备一般500万一套，但是Facebook现在有近万台的服务器，这是一笔极为庞大的资金。

3.常规数据库的集中式数据库很难解决海量用户 MySQL的分布式数据库正好适合；

4.MYSQL可以定制化，更适应Facebook业务发展需要。oracle等无法定制，不能满足每个不同企业的定制化数据要求。所以mysql数据库会越来越火，也越来越受到企业的重视。

总的来说是，MYSQL更加省钱，Oracle价格太贵，另外就是可定制化。

MySQL 早期就是为 Web 应用而生的，而 Facebook 正是此领域的业务场景；另外从成本价格来讲，MySQL 开源免费的，Oracle 价格高。在版权上，大公司更注重版权，开发人员也不能随便用盗版，所以，如果全部用正版数据库，肯定增加成本的。而 MySQL 开源免费。当然，也并不是说 MySQL 没啥优点。MySQL 作为是一种开放源代码的关系型数据库管理系统（RDBMS），任何人都可以在 GeneralPublic License的许可下下载且个性化优，另外，MySQL 的可靠性，速度以及它适应性强而受人欢迎。提供用于管理、检查、优化数据库操作的管理工具 用其来管理内容无疑是很好的选择，而且 MySQL 数据库系统使用最常用的为数据库管理语言--结构化查询语言（SQL）进行数据库管理。不仅如此，MySQL 其自身的特点也是它的加分项。它支持AIX、FreeBSD、Windows等多种操作系统。不仅能够作为一个多带带的应用程序应用在客户端服务器网络环境中，还能够作为一个库而嵌入到其他的软件中提供多语言支持。虽然其他的大型数据库例如 Oracle、DB2、SQL Server 等相比，MySQL 自有它的不足之处，如规模小、功能有限等，但是这丝毫也没有减少它受欢迎的程度 。当下 IT 行业的走向是开源化、免费化。这就意味着个人可以定制更加具有个性化需求的数据库，从而节省开销。这点上 MySQL 是符合的，ucloud巴巴等大型项目也用了 MySQL ，主要用了分布式存储、缓存、分表分库等技术，灵活运用而已。当然，现在许多的数据库的功能虽然很强大，但经常性使用的无非几种，或者有些比较适合自己使用的功能, oracle 等无法定制。所以 MySQL 这种开源的数据库会越来越火。另外，Facebook 也并非一成不变使用 MySQL，节省开销是一回事，但体验使用质量好更是一回事，新的需求产生会催促其进行升级成长，比如 Facebook 建 立了自己的 Cassandra 数据商店并且在其网站上重点推出一项新的搜索功能。据Facebook的工程师 Avinash Lakshma 介绍，Cassandra 仅用 0.12 毫秒就可以写入 50 GB 的数据，比 MySQL快了超过 2500 倍。Twitter公司也计划从 MySQL 迁移到 Cassandra 数据库，因为后者具有更大的弹性、可扩展性和大量的社区网络开源开发人员。欢迎更多交流留言评论 !

其实不止是Facebook，大部分互联网公司都是在使用Mysql数据库（会辅助使用Nosql数据库，这里暂时不讨论）。

首先不能否认的是，如果是按照单库运行，Oracle、DB2这些商业数据库还是很强大的。IT公司的传统套路就是IOE，其中O就是指的Oracle。另外I是指IBM的服务器，E是指EMC列阵存储。三个加起来很强大，基本上可以支持一般的企业的业务，当然，也很贵，非常贵。

当到了Facebook这个级别的公司，数据量可不是几千万，几个亿这个级别的了，这时候如果数据还是单机的话，已经很难支撑基数大、增长快的数据了；这时候的做法就是分库，把数据保存到不同的数据库节点上。

这时候Mysql的优势就显示出来了：

• 开源，就意味着免费，也就节省了License的费用；
  

• 也是因为开源，所以有能力的公司都会对公开版的Mysql做二次开发，跟进业务的需要去改造Mysql；
  

• 服务器的钱也省下来了，也不必使用费用很高的服务器了，这一点又是省钱。
  

总之，Mysql省钱，还能定制改造。

希望我的回答，能够帮助到你！

我会持续分享Java程序开发、架构设计、职业发展等方面的知识和见解，希望能得到你的关注今日头条【会点代码的大叔】，转载请注明出处。

1.facebook确实在使用MySQL，主要是因为免费开源，因为免费降低了成本，也因为开源，其可定制化比较强，基于MySQL的第三方版本也比较多。facebook自己就基于MySQL搞了一个MyRocks数据库。

RocksDB是FaceBook基于Google开源的LevelDB实现的，使用LSM(Log-Structure Merge）树来存储数据。Facebook开发工程师对RocksDB进行了大量的开发，使其符合MySQL的插件式存储引擎框架的要求，移植到了MySQL上，并称之为MyRocks。MyRocks支持基于SQL的数据读写、锁机制、MVCC、事务、主从复制等MySQL绝大部分功能特性。从使用习惯考虑，使用MyRocks还是使用MySQL/InnoDB并没有多大区别。

2.数据量大的问题，主要是通过分布式和分库分表来解决的，并不是单机存储。oracle的缺点就在于这，oracle虽然单机数据处理量大，但是对集群和扩展的支持比较差。mysql单机不行，但是可以集群啊，集群不够，还可以分布式啊。况且facebook这种业务，也不适合oracle。

3.facebook

4.历史原因和使用习惯导致的，这也是为什么没有选择另外一个开源数据库postgreSQL的主要原因。

所以，可以这么说，facebook数据量大是一个问题，但是并不是完全或者说多带带依赖MySQL全部解决的。

2004年成立的Facebook很快便占据了社交网站的榜首，智能手机出现标志着互联网全面转向手机端，在移动互联网时代Facebook的APP也同样霸占着社交APP排名榜首。有很多网友就非常好奇Facebook使用哪个数据库来存储庞大的用户资料？通过了解社交网络的老大哥Facebook的数据库演变，从中吸取宝贵的经验教训。

Facebook中的个人资料不仅仅是姓名、Email、兴趣等属性列表，而是一个非常丰富的社交图谱，包括了亲人/朋友、群组、喜欢、分享等等。刚开始的Facebook社交页面非常简单，采用PHP来构建应用程序，MySql作为长期使用数据库，采用Memcache作为后备缓存支持。PHP应用程序可以直接访问MySql和Memcache，中间没有数据抽象层。

这种简单的数据库架构在访问量很少的情况下优势确实非常明显，但Facebook从2005年开始用户量就飞速增长，最终这种数据架构导致了开发人员敏捷性急剧下降。因为工程师需要使用两种截然不同的数据模型来对数据进行处理，MySql存储主从对集合、Memcache则用于存储和提供派生的平面键值的SQL查询，MySql和Memcache相互协作成为了一个很大的难题，开发者使用数据库前首先要获得关于这两个数据库如何相互协作的复杂知识。

Facebook的数据量暴增也使得MySql的缺点凸显出来，MySql的单体架构很早强制应用程序级的分片，应用程序则需要跟着哪个MySql实例复杂存储哪个用户的配置文件，数据量暴增之后，开发和操作的复杂程度就呈现指数级增长。多数据中心、异地冗余复制也成为了MySql一个非常关键性的问题，主从异步复制转移时，最近的数据无法避免不会丢失。

于是Facebook自2009年开始自研构建小而美的存储系统TAO

TAO可以将facebook现有成百上千的Mysql主从对转化成一个高度可扩展、自动分片、基于地理分布式的数据库集群。TAO可以将分片迁移或者克隆到同一个集群的不同服务器，这样就能平衡负载并消除负载峰值。

如果一次分片更新后、第二次分片更新前出现故障，TAO的异步修复作业就会清除挂起的关联。

使用TAO架构之后本质上还是没有放弃MySQL，因为当时的MySQL和其他数据库都无法多带带解决爆炸式数据量的增长。TAO本质上只是创建了一个自定义数据库的查询层，这层抽象了底层分片的MySql数据库。

分布式SQL应运而生

很多人都喜欢SQL普遍性以及灵活性，都不愿意放弃SQL的情况下对它进行扩展。虽然很多企业没有Facebook这样大规模数据增长的问题，也同样希望按照自己的意愿来拓展SQL数据库。

第一波分布式SQL数据库叫做NewSql，包括了Clustrix、NuoDB、Citus、Vitess等等，但这些都不足以从根本上简化开发人员、运营的体验，反而阻碍了开发人员。于是就有了第二波分布式SQL数据库，灵感源于Google的Spanner,数据库层内置了大规模可扩展性和全球数据分布，而不需要像之前Facebook必须内置在应用程序层中。

总结

Facebook、Google等等这样的科技巨头的数据库扩展的历程，都是值得很多人学习和借鉴的。TAO保留了MySql的现有投资，但应用工程师失去了使用SQL的能力。Google则创建了Spanner，走了一条不同的道路创建了一个全新的SQL数据库。

以上个人浅见，欢迎批评指正。

认同我的看法，请点个赞再走，感谢！

喜欢我的，请关注我，再次感谢！

看到很多回答，不少都是不懂装懂。很多人还扯到性能上。MySQL作为互联网数据库标配时，MySQL的性能，稳定性都不好。

互联网公司采用MySQL，真正的原因，也是唯一的原因，就是开源免费。

互联网数据的两个特点决定了MySQL是首选，一个特点是互联网针对的用户群巨大，大的互联网公司数据库服务器成百数千，一个oracle版费几十万，这个费用太巨大。另外一个特点，绝大部分互联网数据的重要性远低于银行电信，甚至一般企业业务，比如一个用户的留言，一个帖子，真丢了，只要不是普遍现象，后果不严重，这也是早期MySQL不稳定，备份机制也不好时，但仍成为互联网标配的原因。

现在很多大型互联网公司，数据库其实既有MySQL，也有oracle，依据数据类型来使用不同数据库。

欢迎关注我，一个程序员老司机，和你分享编程、运营、需求等等经验和趣事。

从你的问题描述来看，我觉得这是一个伪命题，在这个行业，很多人都流传着一个所谓经典的名言：‘如果MySQL数据库存储记录超过一百万的时候，性能会有很大的折扣’，但是结果facebook却能够很好的运行，下面我们就来分析一下原因。

原因一

为了应对高性能的应用，我们的MySQL也在不断的改进，不断的引入很多高级的功能，比如表分区、复制和集群等，还引入了Memcached，利用好这些功能，能够让我们的应用程序性能大大的提高，同时也能够处理好存储大数据的问题。

原因二

我们知道MySQL是开源的，什么意思呢？就是我们能够对MySQL的源代码进行修改然后编译，从而实现属于我们的定制化的MySQL，所以Facebook也对MySQL进行了修改，删除了很多不需要的功能，添加了很多自己需要的功能，尤其是将一些认为效率低的东西彻底移除，打造属于Facebook的定制化MySQL，这应该是MySQL能够胜任Facebook的根本原因。

原因三

虽然数据库提供了很多我们需要的功能，但是为了提高应用的性能，我们很多时候不一定要借助数据库来完成，比如实现一些统计功能，我们可以不借助数据库的存储过程来实现，而是采用应用程序的方式来实现，让数据库只做一件事：就是数据管理，不做太复杂的数据处理操作。

希望能够帮助到你，还有什么疑问，可以在评论中进行交流。