8 個不得不說的 MySQL 陷阱

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 付費，比本身來編寫代碼要便宜得多。有時商業的、不開源的代碼是有意義的。事實不言而喻。

 

英文原文：http://www.pcadvisor.co.uk/news/software/8-mysql-gotchas-worth-a-rant-3620577/