Facebook 用戶量十分龐大，為什麼還使用 MySQL 資料庫？
首先需要承認，Oracle目前還是最先進的關係資料庫，其傳統使用方法：存儲使用EMC陣列（容量大，數據安全），IBM伺服器，即IOE組合，這三個組合很強大（高可用，高性能），但是也高價格（二樓介紹了，百萬級別），如果數據量不大，這種單機（通常會配置一套異地備庫用於容災）解決方案是可以支撐起大多數傳統企業的業務的
Facebook是一個有10億用戶的互聯網公司，擁有海量數據，而且增長很快，單機資料庫完全無法滿足這種需求，這時需要對數據進行分片，存儲到多個資料庫節點中，這個時候如果使用IOE作為其中一個節點，肯定可以保證很好的性能，但是成本就非常非常非常高了，要知道，Facebook的資料庫伺服器有成千上萬台。。。
這時MySQL的優勢就顯示出來了：1:）省去了巨額license費用；2）MySQL代碼開源，可以根據業務特點定製和優化；3）將MySQL運行在普通PC上，硬體費用大大降低
另外，使用開源的方案可以避免對Oracle過度依賴，當你只有一個選擇時，對方可以隨便要價
總結起來：1）省錢，如果Oracle價格便宜，作為分散式節點當然可以提供比MySQL更好的性能，但這不可能
2）擴展性，MySQL源碼可見，全球很多開發者幫助優化，可以出錢請專業團隊定製功能（如percona，mariadb公司），且不受Oracle公司控制，發展空間更大
1.MySQL早期就是為Web應用而生的，而FB正是此領域的業務場景；
2.若是使用商業資料庫產品，你知道需要多少License費用嗎？以Oracle為例官方報價一般25/CPU核，以及採購小型機一般80-120萬/台，存儲設備一般500萬一套；
3.集中式資料庫很難解決海量用戶 和海量數據的問題，用商業資料庫做分散式架構，則成本更高。
4.互聯網企業都是依靠 技術 解決問題，而不單單依靠 商業產品解決問題。
總結：首先使用商業資料庫產品解決不掉FB的問題；其次使用MySQL的成本 可能是 商業產品的 30%左右；論文原文：
In Facebook, Edge caches and the Origin cache handle an aggregated 90% of the traffic. For the most popular 0.03% of content, cache hit rates neared 100%.(Astonishing)
Facebook用戶量大的問題由它的分散式緩存系統主要解決，剩下的自然是開源的mysql更合適了
上圖是Facebook的photo訪問服務圖，實際上你可以看見，資料庫是在最末端，Cache層已經服務了90%的需求，對於熱點圖片命中率接近100%，不是說資料庫已經不重要了，而是這種重要性降低了，資料庫並不是直接與用戶進行交互，中間隔了好幾層高速Cache，在這種情況下，用自己定製的（注意是定製的）免費的Mysql已經足以滿足這匯總需求，何必再去花更多的錢了？
同時，Facebook上所有用戶進行讀的操作遠大於其寫的操作，因此Cassandra這樣的寫非常快的NoSQL資料庫，Facebook並沒有採用。
CSDN上剛有了一篇文章，關於餘額寶的去IOE，建議看一下：從Oracle到MySQL，餘額寶雲實踐分享-CSDN.NET
1. 規模大，開源方案節省成本，MySQL在開源社區成熟度最高
2. 有MySQL方面的牛人人，面對出現的問題，可以很好的解決問題
3. 大規模數據存儲沒有穩定成熟的方案，oracle 只是有基礎和技術實力，但是沒有場景
這個問題題主已經有了一個主觀的判斷，就是MySQL是一個不太好的資料庫。
作為MySQL從業者，我當然知道，Oracle才是世界上最先進的資料庫，但是，這並不代表MySQL不行，主要看你怎麼用。用MySQL一方面節省成本，另外一方面，還可以為公司做一些技術儲備。
春晚紅包這麼大的量，後面全部是MySQL資料庫，估計題主會覺得很不可思議吧！而且，這還是金融數據，比Facebook的數據還要重要一些，並發量也不少。
- 自由度：開源軟體可以在遵守協議的情況下任意修改以適應 Facebook 的各種應用場景，還有 BUG 的修復也不必苦等廠家漫長的補丁發布，出現問題也不對看著一堆莫名其妙的日誌不知所措，直接找源碼解決。Oracle 雖然有 7*24 小時的技術支撐，但一是流程慢，二是未必可以解決問題，三是這個也要收費。
- 耦合度：用了 Oracle，那麼容災最好就用 GoldenGate，集群最好用 RAC 等等，如果這些產品不用 Oracle 的，那麼出了問題是要三方協調排查的，很麻煩。而且這些產品是需要另外付費購買的。
- 價格：初創時為節約成本，且發展前景未知的情況下，如無必要不會選擇商業軟體。
- 技術積累：對於一個公司來說，這是應該是非常重要的資源，更換資料庫應該需要足夠的且無法繞開理由。
商業軟體的優勢是非常穩定、標準實現度高，有技術支持，對於互聯網來說這些都不是最重要的問題。
1. 公司成本考慮，使用mysql不需要授權費
2. 招聘成本考慮，會寫mysql語句的碼農多，看過mysql源碼的碼農也多，同時mysql管理dba也很多
3. 二次擴展成本考慮，mysql接入一個新的引擎成本不高，修改引擎內代碼或微調，成本也不算高
4. mysql開源較為活躍，5.6，5.7，以及最近的多節點同步方案都大大增強了mysql可用性，這屬於開源界可以帶來的持續紅利
阿里巴巴，淘寶等都使用MySQL。理由都差不多。
就比如，你是開一個飯店，你飯店賣的最好的是酸辣土豆絲，涼拌黑木耳，水煮肉片，蔥油鱸魚，冰糖蒸老南瓜，剁椒鯽魚，梅乾菜扣肉，剁椒魚頭，剁椒魚塊，香乾臘肉，香乾五花肉，冰糖南瓜， 干豆角扣肉，粉蒸排骨， 肉沫蒸蛋，毛豆蒸臘鴨腿，泡椒仔排，剁椒蒸芋艿，蘿蔔乾燒肉，錢江肉絲，蔥爆豬肝，水煮肉片，青椒雞雜，泡椒帶魚，肉沫鯽魚，香辣雞米花，清蒸醬鴨，家燒鯿魚，番茄炒蛋，蝦皮西葫蘆，酸辣白菜，洋蔥炒蛋，肉沫冬瓜，豆角肉絲，苦瓜肉片，金針菇肉絲，韭菜豆芽，地三鮮，珍菇燉花蛤，紅燒日本豆腐，土豆牛腩，干鍋茶樹菇，干鍋啤酒鴨，玉米小排湯...
不好意思，一說起吃的就收不住嘴，說正事，你每天關注的其實是利潤有多少，結果發現成本項裡面，切菜刀（oracle）要1000塊（一整套，有切絲的，有雕花的，有斬骨頭的...），但是市場上竟然也有一分錢不要的殺雞用的牛刀（mysql），雖然切菜沒有那麼利索，但是也能用，而且這個牛刀不鋒利了，磨磨改改就好了，而你的大廚都是新東方請過來的最高水平的廚師，你們一商量，就拍板說，用牛刀
大家已經談了很多使用MySQL的理由，不過我覺得題主不單單是在問Why，其實還問了How，即 Facebook用戶量如此之大，用MySQL怎麼能搞得定？因此在下斗膽補充兩句
今天許多大型互聯網項目都會選用MySQL（或任何關係型資料庫） + NoSQL的組合方案- 關係型資料庫適合存儲結構化數據，如用戶的帳號、地址
- 這些數據通常需要做結構化查詢（嗯，好像是廢話），比如join，這時候，關係型資料庫就要勝出一籌
- 這些數據的規模、增長的速度通常是可以預期的
- 事務性、一致性
- NoSQL適合存儲非結構化數據，如文章、評論
- 這些數據通常用於模糊處理，如全文搜索、機器學習
- 這些數據是海量的，而且增長的速度是難以預期的，
- 根據數據的特點，NoSQL資料庫通常具有無限（至少接近）伸縮性
- 按key獲取數據效率很高，但是對join或其他結構化查詢的支持就比較差
嗯，好像在答SQL vs NoSQL了，不過就是基於它們的適用範圍不同，目前主流架構才會採用組合方案，一個也不能少。目前為止，還沒有出現一個能夠通吃各種場景的資料庫，而且根據CAP理論，這樣的資料庫是不存在的。
所以我們可以說，Facebook不能例外，也是需要使用關係型資料庫的，至於Why MySQL，各位的回答已經很完備了。
另外，關於Facebook是如何使用MySQL的，還請各位大牛補充。。。
上邊的回答說的很詳細了，開源的免費是互聯萬今後的一個趨勢和方向，大的互聯網公司都在去O，一方面是降低成本，另一方面，也說明 ORACLE並非無可替代，MYSQL+NOSQL 這個組合，也逐漸被很多的公司使用。ORACLE 有非常強大的計算能力，多表join和子查詢，也不是mysql能相提並論的，但是也不得不說 隨著國內IT企業不斷的摸索，開發人員知識能力也在普遍提高，處理高並發高性能海量數據的能力 跟以前相比，已經有了大幅度的提高。越來越多的公司 已經有了專門的DBA部門，人數也不少。這就說明了，現在企業不會完全依賴於ORACLE，高並發大數據他們有了另外的解決方案。mysql join 不行 我就不用mysql join ,mysql子查詢弱，我就不用子查詢，讓redis，memcache 配合mysql 也可以實現這種高性能的查詢啊。
facebook 在 TAO 的論文里有講一點這方面的選型。既然是自己輪了一套存儲層，理論上底層存儲可以靈活選擇，比如底層存 RocksDB 架構上會不會更清晰直接？論文里提了仍選擇 mysql 的幾點考慮與設計權衡：
4.1 Storage Layer
Objects and associations were stored in MySQL at Facebook
even before TAO was bui< it was the backing store
for the original PHP implementation of the API. This
made it the natural choice for TAO』s persistent storage.The TAO API is mapped to a small set of simple
SQL queries, but it could also be mapped efficiently to
range scans in a non-SQL data storage system such as
LevelDB [3] by explicitly maintaining the required indexes.
When evaluating the suitability of a backing store
for TAO, however, it is important to consider the data
accesses that don』t use the API. These include backups,
bulk import and deletion of data, bulk migrations
from one data format to another, replica creation, asynchronous
replication, consistency monitoring tools, and
operational debugging. An alternate store would also
have to provide atomic write transactions, efficient granular
writes, and few latency outliers.Given that TAO needs to handle a far larger volume of
data than can be stored on a single MySQL server, we
divide data into logical shards. Each shard is contained
in a logical database. Database servers are responsible
for one or more shards. In practice, the number of shards
far exceeds the number of servers; we tune the shard to
server mapping to balance load across different hosts. By
default all object types are stored in one table, and all
association types in another.
-- https://www.usenix.org/system/files/conference/atc13/atc13-bronson.pdf
alisql源碼已開放：https://github.com/alibaba/AliSQL，歡迎品嘗！
觀念在改變.
對資料庫的功能要求在一直的減少.
資料庫內置的各種高級特性正在被各種各樣的應用伺服器取代.資料庫伺服器越來越純粹,就是安全的保存數據.
甚至就連數據緩存,現在的趨勢也是越來越重視應用伺服器端的緩存.而不是把更多的精力放在資料庫緩存那.
至於原因?很簡單,服務支持再好的資料庫,其進化周期也遠遠的大於應用服務的進化.
這個問題，可以說網上好多答案，至於為什麼用mysql或者說為什麼沒有用高貴的oracle和「貴足」db2，這個也是仁者見仁智者見智，我自己結合我看到的幾家公司的情況，自我感覺應該是如下：
1.當下IT行業的走向是開源化、免費化。開源話就意味著我可以定製更加符合我自己需求的資料庫。免費可以節省我的開銷。
2.可定製的呼聲越來越高。現在死板的資料庫，功能是很強大，但是功能強大，用到的也無非那幾個功能，或者有些比較適合自己使用的功能，oracle等無法定製。所以mysql這種開源的資料庫會越來越火。不過mysql在oracle的帶領下，更新速度明顯降低，這應該是oracle本身的問題而不是mysql的問題，當某天mysql消失的時候，肯定會有一個更加優秀、開源、可定製性更高的資料庫來代碼mysql。
3.軟體的利潤逐漸降低，朝著一個：你買我硬體，我送你配套的軟體，靠硬體和服務來獲取利潤的方向發展。預估幾年後，蘋果的ios和mac系統、微軟的windows系統將會慢慢的降低費用或者直接免費，但這兩家公司短時間內應該不會開源，代碼還是他們的一筆不可忽視的財富。
兩點，成本和自由度
MySQL在效率上一點也不差…
大多數影響效率的是寫法及用法
很簡單的一個例子就是大部份寫網站都是前台發貼，後台就把貼插到數據庫中，但這種做法很傻，因為讀與寫I/O的成本很高，而且還觸及鎖等問題，像facebook 推特twitter 這樣高流量的網站根本不會這樣做。
更好的方式是用 Event sourcing 的方法，去減少數據庫的負擔，直接把事件流存在內存中，更改數據庫只會是定時 snapshot 一下或者是儲存一些不用即時更新的數據。
至於MySQL之所以為巨企所愛，也是因為他成本低， 高效率， 最重要的是他們有人才去維護解決一些開源的軟體的潛在問題，在MySQL被Oracle收購之前，很多公司都會認為用MySQL不會助長其他業界對手…
現在MySQL被Oracle收購後，很多公司已經開始轉到Maria DB現在都沒人發這個鏈接嗎？
https://www.facebook.com/MySQLatFacebook/notes裡面可以解釋不少facebook是怎麼用mysql的，facebook對mysql的補丁一直是開源的，應該就在lauchpad上有。
https://www.facebook.com/notes/mysql-at-facebook/my-mysql-is-faster-than-your-mysql/10151250402570933mysql 5.6在編譯時去掉 「performance schema」 的性能，以及facebook自己用的5.1加FB自己補丁的性能。
人家用的是"定製版"的mysql，你用的是"公開版"的mysql。
為什麼總認為mysql比不上oracle呢，阿里現在都在去o呢。
1，php和mysql是好基友，而fb用的是php語言。
2，mysql開源可定製，而oracle這點相差太遠。
3，費用問題。
感覺潛台詞是「mysql過時了，怎麼配得上facebook的體量，怎麼不用點現在領先的」。
這個問題非常有國內特色: 關注「用什麼技術」，「底下的東西是否新穎前沿」，超過了關注實際取得的效果。可能也是技術人員喜歡「玩一個前沿技術」的簡歷思維的直接體現吧。
此外，facebook下面用的存儲非常的多，具體服務情況具體選擇和優化。光是把rockdb封裝之後的kv存儲變體就有至少兩個吧。
mysql一直是當作最核心的用戶賬號信息存儲，是直接sharding的，其實基本就是當作點對點kv用，不用太複雜的foreign key什麼的，應該也非常避免範圍操作，非常穩定非常可靠，而且市面上有豐富的mysql db和他們的運維經驗可以保護這個公司的最核心庫。
非核心用戶賬號信息的，比如機器學習相關的，或者瀏覽歷史的，這些比較軟性的東西，facebook也試過cassandra和hbase，都不靠譜，這些開源社區炒的很火的玩具項目，基本都廢掉了。後來主要依賴自己的rocksdb。推薦閱讀：