鬆哥上學那會,不少人對 MySQL 有一些偏見,偏見主要集中在如下幾方面:數據庫
這麼多年過去了,鬆哥本身在開發中一直是以 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 存儲引擎主要有以下特色:
固然也不是說 InnoDB 必定就是好的,在實際開發中,仍是要根據具體的場景來選擇究竟是使用 InnoDB 仍是 MyISAM 。
因此第一個問題不攻自破。
第二個問題確實是一個硬傷。
你要是拿 MySQL 和 Oracle 比,確定是要差一點點感受。畢竟一個免費一個收費,並且收費的還很貴。可是這個問題並不是無解。
相信不少小夥伴都聽過國內不少大廠都使用了 MySQL 來存儲數據。大廠用 MySQL ,是由於他們有能力研發出本身的存儲引擎,小廠通常沒有這個實力,無法去研發出本身的存儲引擎,可是 Oracle 又用不起,那麼怎麼辦呢?
這幾年興起的分佈式數據庫中間件恰好能夠很好的解決這個問題。Java 領域,相似的工具不少,例如 Sharding-JDBC 、MyCat 等,經過這些工具,能夠很好的實現數據庫分庫分表,以及數據表的動態擴展、讀寫分離、分佈式事務解決等。有了這些工具,極大的提升了 MySQL 的應用場景。
另外一方面,近些年流行微服務,這不是單純的炒概念,微服務架構將一個大的項目拆分紅不少個小的微服務,各個微服務處理本身很小的一部分事情,這更符合人類分工協做的特色。在微服務架構中,咱們對大表的需求、對多表聯合查詢的需求都會有所下降,MySQL 也更具用武之地。
所以,第二個問題也是能夠解決的。
據鬆哥瞭解,互聯網公司使用 MySQL 仍是比較多的,傳統軟件公司,可能會更青睞 Oracle 等數據庫。
不過話說回來,雲計算,也是將來一個方向。
爲何要寫這篇文章呢?由於鬆哥打算出幾篇文章給你們介紹一下分佈式數據庫中間件 MyCat 和 Sharding-JDBC 的用法,有了這些分佈式數據庫中間件,就可讓你的 MySQL 真正具有能夠媲美大型數據庫的能力。本文算是一個引子吧。
後面鬆哥就先更新 MyCat 。
關注公衆號【江南一點雨】,專一於 Spring Boot+微服務以及先後端分離等全棧技術,按期視頻教程分享,關注後回覆 Java ,領取鬆哥爲你精心準備的 Java 乾貨!