吐槽時間到——劍指大家都喜愛的高人氣關系數據庫
mysql易于安裝、速度相對出色而且包含豐富的功能選項。如果單憑這些還不足以吸引你，它同時也是開源運動當中最具代表性的旗艦性項目之一——它的成功故事告訴我們，一家以開源為立足根基的企業同樣能夠獲得巨大成功。
令人不禁怒吼wtf的八大mysql常見問題
然而，相信每一位使用過mysql的朋友都曾經出于某種理由將自己的怒拳揮向屏幕——哐!!!雖然平心而論，我們不可能建立起一套能夠存儲成千上萬條互聯網信息的技術體系，又要求其從來不出任何差錯。但是，一旦差錯出現，一股恨意總會涌上大家的心頭——也包括我自己。
在今天的文章中，我們整理出關于這套開源關系數據庫的八大漏洞，而這些正是經常導致用戶神經錯亂的元兇所在。其中一部分并不限于mysql本身，它們會在各類關系類數據庫當中頻頻出現。但如果不把關系類數據庫跟mysql進行明確劃分，那么我們將永遠生活在上世紀九十年代。所謂不破不立，正視問題也就是解決問題的第一步(當然，大家也可以選擇存在時間還不太長的其它新型數據庫，但它們同樣也是問題纏身——必然的)。
深層缺陷與特有問題
任何一套規模龐大的軟件包都會存在漏洞。不過從深層角度來看，mysql的各類漏洞已經形成了自己的一套風格與體系。在選擇mysql的同時，大家必須馬上集中注意力——因為在這里，null的作用在不同情況下會發生改變，而外鍵約束的效果亦往往與我們的期望不符……就連自動遞增都會鬧出各種意料之外的麻煩。
mysql當中存在著幾十個這樣的小問題，而且它們時不時就要跳出來折騰一番。有鑒于此，一部分用戶專門整理出了清晰的錯誤清單。但mysql至少擁有一套出色的漏洞報告系統，因此我們可以了解到那些自己尚未意識到或者遇到過的潛在問題。遇上錯誤別激動，其他人也在經歷著同樣的命運。
關系表欠缺靈活性
表帶來了紀律性，紀律性絕不是壞事——但強迫程序員們不得不按照僵化的預定義列打理數據就很令人頭痛了。nosql之所以能夠在短時間內迅速風靡全球，就是因為它為程序員提供充分的靈活性，允許他們隨時對數據模型加以強化。如果需要為聯系地址添加一行新內容，大家可以在nosql當中輕松通過插入來實現。而如果各位打算添加任何一個完整的新數據塊，nosql模型也能夠順利加以接納，而不會強行要求用戶以預設方式進行提交。
想象一下，我們可能剛剛創建出一套以整數形式存儲郵政編碼的表。它的效率很高，而且所采用的強制規則也完全可以接受。接下來，有人發送了一條包含連字符的九位郵政編碼、或者收到一封包含有加拿大地址郵編的信件，這時我們該怎么辦?
這時，相信大家和我一樣，聽見了夢想破壞的聲音……老板希望網站能在幾小時內順利上線，因此我們根本沒時間對整套解決方案進行重構。那么程序員該怎么做?也許需要利用一些小技巧將加拿大的郵政編碼轉化為base64數字，再將其轉換回base10?又或者利用一條專門的轉義碼設置輔助表，從而聲明真正的郵政編碼其實被保存在其它位置?誰知道呢。我們有幾十種解決問題的辦法，但這些小訣竅總會帶來其它潛在麻煩。不過沒轍，時間緊迫，網站不能按時上線、我們是要丟飯碗的。
mysql的關聯規則原本希望能讓每位用戶都抱有誠實謹慎的好心態，但實際上卻讓我們不得不通過小聰明來規避這種約束。
join
曾幾何時，將數據拆分成多個表代表著計算機科學領域的一大卓越進步。這不僅意味著我們能夠顯著降低表的大小，同時也為用戶帶來良好的簡化效果。但在join語句當中，這種紀律性與收益開始要求我們為之付出代價。
在sql當中，還沒有哪部分組件能像join這樣逼迫開發人員建立一系列復雜語句，并承受由此帶來的混亂與絕望。在此之后，存儲引擎還需要找到最優方式來高效解壓這些join語句。總而言之，這相當于開發人員被迫建立起復雜的查詢表述，而數據庫則被迫對其進行梳理。
正因為如此，很多追求速度表現的開發人員干脆放棄了這一進步，轉而采用非規范化方式處理。相較于對條目進行拆分，大家直接將數據對象匯總成一個巨大的表，而這就規避了其復雜性。如此一來，運行速度不僅更快，服務器也不至于(頻繁)出現內存溢出狀況。
如今磁盤存儲空間已經相當廉價。市場上已經出現了單磁盤8 tb產品，而容量更大的方案也即將亮相。所以相信在不久的將來，我們將徹底告別該當活剮的join。
更多信息請查看IT技術專欄
公眾號
事業單位
當前位置：
公考類
招聘類
各類考試
