Mysql安裝簡單，速度較快，功能豐富。另外它還是開源運動的標桿，它的偉大成就向我們展示了一個成功的公司是可以建立在開源程式碼之上的。
然而用過mysql的人都曾對著顯示器揮舞過拳頭。但你不可能發明一種每秒能保存成千上萬行網路數據，並且一點錯誤都沒有的技術吧。
為了在這個夏天躁起來，我們列舉了8個抱怨開源關係型資料庫的理由。以下列舉的理由中不僅限於 MySQL，有些是針對關係型資料庫的。如果我們沒有理清楚關係型資料庫和 MySQL，我們將會永遠陷入90年代的思想。我們需要推倒然後重建這些。或者我們轉向使用一個最近流行的，存在時間沒有長到可以列出一堆像下面一樣的理由的資料庫。
根深蒂固的bugs
任何大的軟體包都有 bug。但稍微深入了解一下，就會發現和 Mysql 相關的 bugs 自成系統。突然你需要留心，因為 NULL 並不是以同樣的方式出現，外鍵約束也沒有像你想像的那樣執行，連主鍵自動增長也會出錯。
小問題大量存在，而且並不總是可以修復，這就是為什麼有些人保持一個清單。還好 MySQL 維護著一個非常好的 bug 報告系統，讓我們可以知道我一些我們無法想像的事情，知道其他人也正在經歷同樣的磨難。
關係表的不靈活性
關係表具有條理性，條理性是好的－但是，它使得程式設計師必須編造或硬塞一些資料到已經定義好模式的列中。 NoSQL開始越來越受到歡迎的原因之一，就是它為程式設計師提供了足夠的彈性，來加速資料庫的使用。如果一個街道地址需要增加一行，那麼，你可以將它輕鬆地插入到一個NoSQL文件中。如果你想新增一個完整的新的資料區塊，無論它包含什麼內容，文件模型也可以原封不動地接受你的數據，而不必改為它要求的資料格式。
試想一下，你用整數格式建立了一個全部是郵編的表格。這個表是十分有效率的，它執行的規則也很好。突然一次，有人上傳了一個使用了連字符的九位數郵編。或者還有可能，你得到了一位來自加拿大客戶的信件，上面寫有郵遞區號。
這時，一切都亂了。老闆要求網站要在幾小時內恢復正常運作。然而，現在已經沒有時間來重建資料庫。程式設計師可以做什麼？或許，可以使用駭客手段把加拿大郵遞區號由base64的數位格式改為base 10格式？或是設定一個使用轉義編碼的輔助表格，用來說明真正的郵遞區號或其他？誰知道呢？到處都有駭客，他們都是危險的。但你沒有時間搞定它。
MySQL的關聯規則讓每個人都誠實謹慎，但它能強制我們避免易受攻擊和欺騙的麻煩。
JOIN聯合查詢
曾幾何時，將資料分錶保存是電腦科學史上的偉大創新。分開後的表格不僅結構簡單，也簡化了使用。但它卻需要使用join語句來查詢。
sql透過一系列join建構的複雜查詢將開發者推入了困惑與絕望的深淵。而且儲存引擎也需要以最優的方式來有效率地解析join語句。開發者需要絞盡腦汁編寫查詢語句，然後資料庫對其進行解析。
這就是許多注重運行速度的開發者放棄資料分錶轉而使用不規範資料表的原因。不區分資料實體，將所有資料保存到一個大表中—以避免複雜的查詢。這樣確實很快，而且伺服器也不會耗盡記憶體。
磁碟空間現在很廉價。 8TB的磁碟已經在售，更大的也要上市了。我們不再需要為使用join而絞盡腦汁了。
分支的混亂
是的，一個可靠的、得到良好支援的MySQL分支，可以帶來競爭和選擇，但它也造成困惑和混亂。更糟的是，一個稱為MariaDB的ＭySQL分支，由Monty Widenius維護著。他同樣也在參與編寫MySQL。那麼，MariaDB才是真正獨立的值得我們擁護的嗎？還是它是MySQL？我們是否應該堅持使用由創建原始MySQL資料庫的組織運營的核心程式碼？或者我們應該加入那些被認為更聰明的，往往很酷的背叛者？
還有，我們該如何獲得關於相容性的資訊？一方面，我們被確信MariaDB和MySQL十分相似。另一方面，我們要相信有差異──不然為什麼大家都在爭論它？也許它們在性能和我們查詢的範圍內，在兩個陣營中工作方式相同？但也許他們不同-或將來會不同。
儲存引擎混亂
MySQL不是事實上的相同的資料庫；它由幾個資料庫組成，它們的大多數細節都被統一的表面所掩蓋。在開始的時候，有一個MyISAM引擎，它很快但在前後一致上不能做到完備。有時候你需要速度並且可以接受不一致的結果時是很好的。
當人們需要更多時，具備完整事務支援的InnoDB出現了。但這還不夠。現在，它可能有20種儲存引擎的選擇——這足以使一個資料庫管理員瘋狂。當然，有些時候在不同的儲存引擎之間切換而不必重寫你的SQL是很好的，但是切換後總是會帶來混亂。這個表格我選擇的引擎是 MyISAM 還是 innoDB 呢？或者，我決定輸出的資料是CSV格式的嗎？
獲利的動機
雖然MySQL 是一款成功的開源產品，但它仍然是一門生意，裡面滿是靠它獲得薪水的專業開發者。當大多數用戶持續享受開源許可證帶來的最佳體驗時，毫無疑問這家公司還在為賺取足夠的錢來維持營運而努力。這導致自由代碼在「社群版」和出售給企業的完整產品之間產生了奇怪的分岐。
你該付錢嗎？你在這裡賺了多少錢？在社群版之上開展經營行為是否公平？企業版中額外的功能，是否只是一個噱頭來引誘我們不斷付費呢？這至少說明一點，它是另一組需要回答的問題。選用哪個版本？遵照哪種許可證？選用它的哪個功能集？
原生 JSON 支援的缺乏
看 MySQL 的年齡最好的方法是安裝它，然後你會意識到需要添加更多的驅動程式使它可用。 MySQL 通常在 3306 連接埠上通信，它一般輸出的是它自己難以理解的格式化資料。如果你想讓你的程式碼和它通信，你必須加入另一層的程式碼，將 MySQL 的語言轉換成有用的東西。這些層的程式碼，以庫的形式分發，經常需要人們購買一個商業的許可證。
現代資料儲存層通常直接以 JSON 通訊。雖然 MySQL 和 MariaDB 現在有能力解析 SQL 中的 JSON 部分，但這還遠遠不夠好，原生的 JSON 介面已經在 CouchDB，MongoDB，或任何最新的工具中廣泛使用。
封閉來源和專有模組的興起
我說過 MySQL 是開源的嗎？它是，但除了一些在」開源核心「週邊開發的一些較新的、非開源的程式碼、專有模組。程式設計師需要吃飯，Oracle需要拿它的辛苦成果來換錢，這是商業的現實之一。它不像那些醫院，使用 MySQL 可以免費醫療照護。它不像那些農民，使用 MySQL 可以贈送食物。
要求 MySQL 永遠堅持在一個很高的標準是有點不公平的，因為開源的成功可能是個圈套。這是因為它開始可以免費，但這並不意味著它可以始終如此。如果企業需要許多新的功能，他們將不得不以這種或那種方式付費。有時向 Oracle 付費，比自己來寫程式碼便宜得多。有時商業的、不開源的程式碼是有意義的。事實不言而喻。
以上就是8 個不得不說的 MySQL 陷阱的內容，更多相關內容請關注PHP中文網（www.php.cn）！
