是選擇Oracle，MySQL還是NoSQL？

oracle全才，無論olap還是oltp，無論是鎖定機制還是事物支援，無論是內建函式還是外部可擴充套件功能，都比較全面。

mysql oltp型選手，但由於缺少 hash join，以及分析函式相對較少，所以olap方面功能相對欠缺，但對事務的支援以及鎖定機制都比較齊全。

nosql k/v 型選手，主要提供高效的簡單查詢，雖然部分nosql產品也支援相對複雜一點的檢索，但在事務以及join方面都未支援，功能最弱。

oracle 需要記錄 redo log 且保證每次事務都fsync到物理磁碟以保證事務安全，連續寫;資料的寫入大多是在記憶體中完成，後台程序進行記憶體到磁碟的定期批量重新整理，隨機寫為主。

mysql innodb引擎與oracle類似;myisam 引擎無事務所以沒有事務日誌到磁碟的fsync問題，但由於其表鎖的原因，併發稍若。從總體使用經驗來看和 oracle 相差不大。

nosql 在資料儲存及日誌記錄方面的架構及實現優化，使之在寫入效能方面較傳統資料庫有較大優勢。

oracle在高併發場景下，由於其在事務控制實現方面的優勢，以及多程序的機制，顯示出了相對明顯的優勢。

mysql在併發數不是太高的前提下，如8，16，32個併發場景下，相對於 oracle 沒有顯示出弱勢，甚至部分儲存引擎下還有一些優勢，但是隨著併發數的增加，就逐步體現出了與 oracle 的差距，這與其基於執行緒的機制也有一定關係。

nosql至少在我過往的多種測試下，大部分時候的簡單查詢效能都不如前二者。

oracle統計資訊涉及的方面非常多，優化器相對於 mysql 來說也先進很多，再加上對 join 方式的全面支援，無論是從功能還是效能角度來說，多表 join 都是 oracle 的優勢所在。

mysql其查詢優化器所能參考的統計資訊相對較少，優化器深度也比 oracle 少很多，所以在多表 join 的時候出現執行計畫異常並不少見。此外，不支援 hash join 的天生缺陷也讓其 join 能力大打折扣。

nosql不支援join，不具可比性，無疑是最弱的。

oracle oracle由於其極高的一致性要求，造成架構上的不少限制。導致其擴充套件成本相對高很多。

mysql原生分布式架構的優勢在於併發支援，但延時問題一直被廣為詬病。所以大部分場景下是人肉進行分布式拆分，但其replication特性加上對一致性的約束相較oracle弱，使其架構靈活性很高。

nosql大多都原生支援分布式部署架構，具有極好的scale out能力。

oracle 這一點上 oracle 具有非常大的優勢，無論是效能跟蹤還是常規維護方面，oracle都提供了非常豐富的工具和系統。

mysql原生工具相對簡單，但由於其開源的特性，有一些第三方開發的工具支援，比如percona提供的一套工具(原mktools)，但總提仍然比 oracle 少了很多。

nosql無論是從效能跟蹤還是常規維護角度來說，都遠不如前二者。

oracle商業軟體，全套的商業服務支援。上百本文件手冊支援，幾乎涵蓋所有的內容。

mysql有商業服務支援，但文件相對簡單，包含的內容也比較少。

nosql少有商業支援，文件非常簡單，網路資料也相對少很多。

oracle發展幾十年，具有充足的人才儲備，活躍的社群環境。

mysql開源資料庫的王者，社群活躍，雖然人才總量常常供不應求，但總體還是處於良性狀態。

nosql新技術，產品眾多，社群活躍度遠不如前面二者，處於人才極度匱乏狀態。

oracle商業軟體，**昂貴。

mysql有開源也有商業版本，但**較便宜。

nosql開源軟體。