吐槽時間到——劍指大家都喜愛的高人氣關系數據庫

MySQL易于安裝、速度相對出色而且包含豐富的功能選項。如果單憑這些還不足以吸引你，它同時也是開源運動當中最具代表性的旗艦性項目之一——它的成功故事告訴我們，一家以開源為立足根基的企業同樣能夠獲得巨大成功。

 [[142171]]  

然而，相信每一位使用過MySQL的朋友都曾經出于某種理由將自己的怒拳揮向屏幕——哐!!!雖然平心而論，我們不可能建立起一套能夠存儲成千上萬條互聯網信息的技術體系，又要求其從來不出任何差錯。但是，一旦差錯出現，一股恨意總會涌上大家的心頭——也包括我自己。

在今天的文章中，我們整理出關于這套開源關系數據庫的八大漏洞，而這些正是經常導致用戶神經錯亂的元兇所在。其中一部分并不限于MySQL本身，它們會在各類關系類數據庫當中頻頻出現。但如果不把關系類數據庫跟MySQL進行明確劃分，那么我們將永遠生活在上世紀九十年代。所謂不破不立，正視問題也就是解決問題的第一步(當然，大家也可以選擇存在時間還不太長的其它新型數據庫，但它們同樣也是問題纏身——必然的)。

深層缺陷與特有問題

任何一套規模龐大的軟件包都會存在漏洞。不過從深層角度來看，MySQL的各類漏洞已經形成了自己的一套風格與體系。在選擇MySQL的同時，大家必須馬上集中注意力——因為在這里，NULL的作用在不同情況下會發生改變，而外鍵約束的效果亦往往與我們的期望不符……就連自動遞增都會鬧出各種意料之外的麻煩。

MySQL當中存在著幾十個這樣的小問題，而且它們時不時就要跳出來折騰一番。有鑒于此，一部分用戶專門整理出了清晰的錯誤清單。但MySQL至少擁有一套出色的漏洞報告系統，因此我們可以了解到那些自己尚未意識到或者遇到過的潛在問題。遇上錯誤別激動，其他人也在經歷著同樣的命運。

關系表欠缺靈活性

表帶來了紀律性，紀律性絕不是壞事——但強迫程序員們不得不按照僵化的預定義列打理數據就很令人頭痛了。NoSQL之所以能夠在短時間內迅速風靡全球，就是因為它為程序員提供充分的靈活性，允許他們隨時對數據模型加以強化。如果需要為聯系地址添加一行新內容，大家可以在NoSQL當中輕松通過插入來實現。而如果各位打算添加任何一個完整的新數據塊，NoSQL模型也能夠順利加以接納，而不會強行要求用戶以預設方式進行提交。

想象一下，我們可能剛剛創建出一套以整數形式存儲郵政編碼的表。它的效率很高，而且所采用的強制規則也完全可以接受。接下來，有人發送了一條包含連字符的九位郵政編碼、或者收到一封包含有加拿大地址郵編的信件，這時我們該怎么辦?

這時，相信大家和我一樣，聽見了夢想破壞的聲音……老板希望網站能在幾小時內順利上線，因此我們根本沒時間對整套解決方案進行重構。那么程序員該怎么做?也許需要利用一些小技巧將加拿大的郵政編碼轉化為Base64數字，再將其轉換回Base10?又或者利用一條專門的轉義碼設置輔助表，從而聲明真正的郵政編碼其實被保存在其它位置?誰知道呢。我們有幾十種解決問題的辦法，但這些小訣竅總會帶來其它潛在麻煩。不過沒轍，時間緊迫，網站不能按時上線、我們是要丟飯碗的。

MySQL的關聯規則原本希望能讓每位用戶都抱有誠實謹慎的好心態，但實際上卻讓我們不得不通過小聰明來規避這種約束。

JOIN

曾幾何時，將數據拆分成多個表代表著計算機科學領域的一大卓越進步。這不僅意味著我們能夠顯著降低表的大小，同時也為用戶帶來良好的簡化效果。但在JOIN語句當中，這種紀律性與收益開始要求我們為之付出代價。

在SQL當中，還沒有哪部分組件能像JOIN這樣逼迫開發人員建立一系列復雜語句，并承受由此帶來的混亂與絕望。在此之后，存儲引擎還需要找到最優方式來高效解壓這些JOIN語句。總而言之，這相當于開發人員被迫建立起復雜的查詢表述，而數據庫則被迫對其進行梳理。

正因為如此，很多追求速度表現的開發人員干脆放棄了這一進步，轉而采用非規范化方式處理。相較于對條目進行拆分，大家直接將數據對象匯總成一個巨大的表，而這就規避了其復雜性。如此一來，運行速度不僅更快，服務器也不至于(頻繁)出現內存溢出狀況。

如今磁盤存儲空間已經相當廉價。市場上已經出現了單磁盤8 TB產品，而容量更大的方案也即將亮相。所以相信在不久的將來，我們將徹底告別該當活剮的JOIN。

混亂的fork

沒錯，穩定且受到良好支持的MySQL fork能夠刺激市場競爭并帶來更多后備選項，但其同時也會引發混亂與困惑。更糟糕的是MariaDB這款fork的出現——作為Monty Widenius負責運營的項目，其背后的支持人員同時也參與了MySQL的開發。那么MariaDB到底值不值得我們采用并信賴?或者說我們更應該選擇MySQL?我們是否應當堅持使用使用由該數據庫原始開發者們所提供的中心代碼?或者轉而投向技術水平更高且技術成果更酷的新陣營的懷抱?

除此之外，我們又該如何解讀關于兼容性方面的信息?一方面，開發團隊告訴我們MariaDB與MySQL在相當程度上能夠實現互換。但在另一方面，可以肯定的是二者之間仍然存在差異——為什么非要腳踏兩條船并為此苦苦掙扎?也許雙方的性能表現接近，而我們的查詢也能夠在其中以同樣的方式起效?但實際情況可能并非如此——或者隨著兩個項目的持續發展而出現背道而馳的局面。

存儲引擎讓人暈頭轉向

MySQL并不屬于真正的單一數據庫;它實際是打著統一的旗號，暗藏眾多更為具體的細節內容。在發展初期，它使用的引擎名為MyISAM，其速度出色但在一致性方面有所欠缺。但這不算什么大事，因為有時候我們確實需要更理想的速度水平，而且能夠承受一致性方面的妥協。

但在人們需要更多方案時，InnoDB攜完整的事務支持能力登場了。但它的表現仍然無法令人完全滿意。時至今日，我們面對著20種存儲引擎選項——其數量遠遠超出了驅動數據庫管理實例的實際需要。誠然，能夠在無需重寫SQL的前提下在不同引擎之間往來切換有時候確實是件好事，但由此帶來的麻煩同樣不容忽視。我到底該為自己的表選擇MyISAM還是InnoDB?又或者最好是以CSV格式進行數據導出?

利益動機

作為一款成功的開源產品，MySQL仍然代表著一整套由專業開發人員構建、且需要據此獲得回報的業務體系。盡管大部分用戶能夠通過開源許可免費享受由此帶來的出色功能，但該公司顯然需要賺取充足的利潤才能持續、健康、穩定地保持發展。這就意味著，以“社區版”旗號免費發布的版本肯定要與面向企業的完整產品有所區別。

那么我們到底需不需要選擇付費方案?大家手頭的資金是否充裕?利用社區版支持商業用例是不是不太公平?企業版當中的額外功能難道僅僅屬于引誘我們付錢的宣傳噱頭?即使大家并不糾結于以上問題，那么以下幾條仍然需要認真考量：我們該選擇哪個版本?采用哪種開源許可?使用哪些功能集?

缺少原生JSON支持能力

可能大家還沒有意識到MySQL的悠久歷史——別擔心，親自安裝一下，各位就會意識到需要添加多少驅動程序才能讓其正常運行。MySQL一般會使用3306端口，而且通常把數據拆分成自己的一種“神秘”格式。如果大家希望利用自己的代碼與之進行交互，則必須添加額外的代碼層將MySQL格式轉化為更具實用性的形式。這些通過庫進行分發的代碼層往往要求用戶購買商用許可。

現代數據存儲層通常能夠與JSON直接對接。盡管MySQL以及MariaDB現在也擁有將JSON解析為SQL組成部分的能力，但其效果還稱不上理想。相比之下，CouchDB、MongoDB乃至其它新型工具都已經開始提供原生JSON接口。

閉源專有模塊的興起

之前我提到過MySQL屬于開源項目吧?事實上，它只能算是以“開源”為核心，同時提供部分新型閉源專有模塊的項目。程序員們必須接受這一殘酷的現實。甲骨文公司為自己的辛苦付出賺得回報，而這也是商業世界所遵循的原則。使用MySQL的醫院不可能免費提供醫療服務，而使用MySQL的農民們也不可能白白提供糧食補給。

雖然給MySQL設定太高的要求標準并不公平，但我們必須承認，說其依賴開源機制取得成功確實不夠準確。憑借開源起步并不代表項目團隊必須一條路走到黑。如果企業用戶希望獲得更多新功能，那么至少需要選擇一家供應商并向其付費。有時候從甲骨文手中購買現成方案要比內部自主研發成本更低。有時候商用、閉源代碼確實效果出色。總而言之，大家需要根據實際情況作出選擇，而不應單純糾結于開源抑或是閉源。

原文標題：8 MySQL gotchas worth a rant