• 大數據的十大局限
• 2016 年 7 個最佳的 Java 框架
• 10個最受歡迎的Java類
• PDF→Excel格式轉換工具集錦！

以下列舉了8個開源關系型數據庫的缺陷，其中不僅限于MySQL，還有是針對關系型數據庫的。只有明白了關系型數據庫和MySQL，才能更好地避免在使用MySQL中盡量少地遇到一些意外。

1、無法避免的bugs

任何一個軟件包都有bug。但稍微深入了解一下，就會發現和Mysql相關的bugs自成體系。突然你就需要留心，因為NULL并不是以同樣的方式出現，外鍵約束也沒有像你想像的那樣執行，連主鍵自動增長也會出錯。

到處都避免不了小問題，而且并不總是可以修復的，這就是為什么一些人保持一個列表。還好MySQL維護著一個非常好的bug報告系統，讓我們可以知道我些我們無法想像的事情，知道其他人也在經受同樣的磨難。

2、關系表的不靈活性

關系表具有條理性是好的，但這迫使程序員要編造或把一些數據塞到已經定義好模式的列中。NoSQL之所以越來越受歡迎，其中一個原因就是它為程序員提供了足夠的靈活性，以加速數據庫的使用。如果一個街道地址需要增加一行，那么，你可以將它很容易地插入到一個NoSQL文檔中。如果你想添加一個完整的新的數據塊，無論它包含什么內容，文檔模型也可以原封不動地接受你的數據，而不必改為它要求的數據格式。

假設你用整數格式建立了一個全部是郵編的表格。這個表十分高效，執行規則也很好。可是有一次，有人上傳了一個使用了連字符的九位數郵編。或者說你得到了一位來自他國的客戶的信件，上面寫有郵政編碼。這時，你會感到一切都亂了。老板要求網站要在幾小時內恢復正常工作。然而，你已經沒有時間重建數據庫。程序員可以做什么？使用黑客手段把這位客戶的郵政編碼由base 64的數字格式改為base 10格式？或者設置一個使用轉義編碼的輔助表格，用來說明真正的郵政編碼或者其他？危險的黑客無處不在，但你沒有時間來搞定它。

MySQL的關聯規則讓每個人都誠實和謹慎，但它能強制我們避開易受攻擊和欺騙的麻煩。

3、存儲引擎混亂

總體來說，Mysql的存儲引擎接口定義還算良好的。MySQL不是實際上的同一的數據庫。它是由幾個數據庫組成，它們的大多數細節都被統一的表面掩蓋了。開始時有一個MyISAM引擎，它很快但在前后一致上不能做到完備。有時你需要速度并且可以接受不一致的結果時是很好的。

當人們需要更多時，具備完整事務支持的Inno DB出現了。但這還不夠。現在，它可能有20種存儲引擎的選擇——這足以使一個數據庫管理員瘋狂。當然，有時在不同的存儲引擎之間切換而不必重寫你的SQL是很好的，但是切換后總會帶來混亂。這個表格我選擇的引擎是MyISAM還是innoDB呢？或者，我決定輸出的數據是CSV格式的嗎？

4、JOIN聯合查詢

曾經，將數據分表保存是計算機科學史上的偉大創新。分開后的表不僅結構簡單，使用上也簡化了許多。但它卻需要使用join語句來進行查詢。

sql通過一系列join構建的復雜查詢將開發者推入了困惑與絕望的深淵。而且存儲引擎也需要以最優的方式來高效地解析join語句。開發者需要絞盡腦汁編寫查詢語句，然后數據庫對其進行解析。

這就是很多注重運行速度的開發者放棄數據分表轉而使用不規范數據表的原因。不區分數據實體，將所有數據保存到一個大表中——以避免復雜的查詢。這樣確實很快，并且服務器也不會耗盡內存。

現在的磁盤空間很廉價。8TB的磁盤已經在售，更大容量的也將上市。我們不再需要為使用join而絞盡腦汁了。

5、分支的混亂

毋庸置疑，一個可靠的、得到良好支持的MySQL分支，可以帶來競爭和選擇，但是它也引起困惑和混亂。更糟糕的是，一個稱為MariaDB的ＭySQL分支，由Monty Widenius維護著。他同樣也在參與編寫MySQL。那么，Maria DB是真正獨立的值得我們擁護的嗎？或者它是MySQL？我們是否應該堅持使用由創建原始mysql數據庫的組織運營的核心代碼？或者我們應該加入那些被認為更聰明的，往往很酷的背叛者？

如何獲取關于兼容性的信息？雖然Maria DB和MySQL十分相似，但它們之間也有差異。這就是大家一直都在爭論它的原因。在性能方面，在我們查詢的范圍內，在兩個陣營中，也許它們的工作方式相同，但也許不同，也許將來會不同。

6、開發MySQL的動機

雖然MySQL是一款成功的開源產品，但它仍屬于商業中的一款產品，專業開發者需要靠它來獲得利益，當然，最直接的利益就是薪資。當大多數用戶在持續地享受開源許可證帶來的最佳體驗時，毫無疑問這家公司還在為賺取足夠的錢來維持運營而努力。這導致自由代碼在“社區版”和出售給企業的完整產品之間產生了奇怪的分岐。

我們應該對這款產品付錢嗎？這種在社區版開展經營的行為是否公平？企業版中額外的功能是不是一個噱頭，以引誘我們不斷付費的呢？這至少說明一點，它是另一些需要回答的問題：選用哪個版本？遵照哪種許可證？選用它的哪個功能集？

7、原生JSON支持的缺乏

通過安裝MySQL查看其年齡，然后你就知道需要添加哪些驅動程序使它變得可用。MySQL通常在3306端口上通信，一般輸出的是它本身難以理解的格式化數據。如果要讓你的代碼和它通信，你必須添加另一層代碼，將MySQL的語言轉換成有用的東西。這些層的代碼，以庫的形式分發，經常需要人們購買一個商業許可證。

現代數據存儲層通常直接以JSON通信。雖然MySQL和Maria DB現在有能力解析SQL中的JSON部分，但這還遠遠不夠，原生的JSON接口已經被廣泛使用于CouchDB、MongoDB，或任何最新的工具中。

8、封閉源和專有模塊的興起

雖然MySQL是開源的，但除了一些在”開源核心“周邊開發的一些較新的、非開源的代碼和專有模塊。程序員也需要賺錢、需要生活，Oracle需要拿它的辛苦成果來換錢，這是一種現實，也是商業的性質。使用MySQL你也不可以免費得到任何東西。

要求MySQL始終堅持在一個很高的標準上，這有點不公平，因為開源的成功可能是一個圈套。它開始可以免費，但并不意味著它可以始終免費。如果企業需要更多新的功能，他們就要通過各種方式付費來獲取。有時向Oracle付費，比自己來編寫代碼要便宜得多。有時商業的、不開源的代碼是有意義的。

MySQL雖然作為一個成功的開源系統，但以上這些問題也總不可避免地出現，這就需要我們在它們發生之前有個深刻的認識，才能在今后的應用中避免不必要的麻煩。