MySQL只能做小專案？是時候說幾句公道話了！

我上學那會，很多人對MySQL 有一些偏見，偏見主要集中在以下幾個方面：

1. MySQL 不支援事務（事實上MyISAM 有表鎖，但效率比較低）

2. MySQL 儲存的資料量比較小，適合小項目，大項目還是得上Oracle、DB2 等

這麼多年過去了，我自己在開發中一直是以MySQL 為主，我覺得我有必要說兩句公道話了。

公道話

第一個問題

關於第一個不支援事務的問題，這有一定的歷史原因。 MySQL 從設計之初，儲存引擎就是可插拔的，允許公司或個人按照自己的需求定義自己的儲存引擎（當然，普通的公司或個人其實是沒有這個實力的）。 MySQL 自研的使用較廣的儲存引擎是MyISAM ，MyISAM 支援表鎖，不支援行鎖，所以在處理高並發寫入操作時效率要低一些，另外MyISAM 也不支援外鍵（雖然現在實際專案中外鍵已經用的比較少了）。

但是這個問題並非無解。這就不得不說 MySQL 中另一個大名鼎鼎的儲存引擎 InnoDB 了。

InnoDB 儲存引擎是由一家位於芬蘭赫爾辛基的名為 Innobase Oy 的公司開發的，InnoDB 儲存引擎的歷史甚至比 MySQL 還要悠久。

InnoDB 剛開發的時侯，就是作為一個完整的資料庫來開發的，因此功能很完備。開發出來之後，創辦人是想將這個資料庫賣掉的，但沒有找到買家。

後來MySQL2.0 推出後，這款可插拔的儲存引擎吸引了Innobase Oy 公司創辦人Heikki Tuuri 的注意，在和MySQL 溝通之後，決定將InnoDB 作為一個儲存引擎引入到MySQL 中，MySQL 雖然支援InnoDB ，但實際上還是主推自家的MyISAM。

但是 InnoDB 太優秀了，最終在 2006 年的時侯，成功吸引到大魔王 Oracle 的注意，大手一揮，就把 InnoDB 收購了。

MySQL 主推自家的MyISAM ，日子過得也很慘淡，最終在2008 年被sun 公司以10 億美元拿下，這個操作鞏固了sun 在開源領域的領袖的地位，可是一直以來sun公司的變現能力都比較弱，最後sun 自己在2009 年被Oracle 收入囊中。那會我還在讀高中，某一天吃午餐的時侯，餐廳的電視機上播放央視的午餐新聞，看到了這條消息，現在還有一些印象。

Oracle 收購sun 之後，InnoDB 和MySQL 就都變成了Oracle 的產品了，這下整合就變得非常容易了，在後來發布的版本中，InnoDB 慢慢就成為了MySQL 的預設存儲引擎。在最新的 MySQL8 中，元資料表也使用了 InnoDB 作為儲存引擎。

InnoDB 儲存引擎主要有以下特點：

1. 支援交易

2. 支援4 個層級的交易隔離

3. 支援多重版本讀取

4. 支援行級鎖定

5. 讀寫阻塞與事務隔離等級相關

6. 支援緩存，既能快取索引，也能快取資料

7. 整個表和主鍵以Cluster 方式存儲，組成一顆平衡樹

#8. ...

#當然也不是說InnoDB 一定就是好的，在實際開發中，還是要根據具體的場景來選擇到底要使用InnoDB 還是MyISAM 。

所以第一個問題不攻自破。

第二個問題

第二個問題確實是硬傷。

你要是拿 MySQL 和 Oracle 比，一定是要差一點點感覺。畢竟一個免費一個收費，而且收費的還很貴。但這個問題並非無解。

相信很多小夥伴都聽過國內很多大廠都使用了 MySQL 來儲存資料。大廠用 MySQL ，是因為他們有能力研發出自己的儲存引擎，小廠一般沒有這個實力，沒辦法去研發出自己的儲存引擎，但是 Oracle 又用不起，那麼怎麼辦呢？

這幾年興起的分散式資料庫中間件剛好可以很好的解決這個問題。 Java 領域，類似的工具很多，例如 Sharding-JDBC 、MyCat 等，透過這些工具，可以很好的實作資料庫分庫分錶，以及資料表的動態擴充、讀寫分離、分散式交易解決等。有了這些工具，極大的提高了 MySQL 的應用程式場景。

另一方面，近年來流行微服務，這不是單純的炒概念，微服務架構將一個大的專案拆分成很多個小的微服務，各個微服務處理自己很小的一部分事情，這比較符合人類分工協作的特質。在微服務架構中，我們對大表的需求、多表聯合查詢的需求都會降低，MySQL 也更具用武之地。

因此，第二個問題也是可以解決的。

據我了解，網路公司使用 MySQL 還是比較多的，傳統軟體公司，可能會更青睞 Oracle 等資料庫。

不過話說回來，雲端運算，也是未來一個方向。

更多MySQL相關技術文章，請造訪MySQL教學欄位進行學習！

以上是MySQL只能做小專案？是時候說幾句公道話了！的詳細內容。更多資訊請關注PHP中文網其他相關文章！