吐槽時間到——劍指大家都喜愛的高人氣關(guān)系數(shù)據(jù)庫

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

令人不禁怒吼wtf的八大mysql常見問題

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

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

深層缺陷與特有問題

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

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

關(guān)系表欠缺靈活性

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

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

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

mysql的關(guān)聯(lián)規(guī)則原本希望能讓每位用戶都抱有誠實(shí)謹(jǐn)慎的好心態(tài)，但實(shí)際上卻讓我們不得不通過小聰明來規(guī)避這種約束。

join

曾幾何時，將數(shù)據(jù)拆分成多個表代表著計算機(jī)科學(xué)領(lǐng)域的一大卓越進(jìn)步。這不僅意味著我們能夠顯著降低表的大小，同時也為用戶帶來良好的簡化效果。但在join語句當(dāng)中，這種紀(jì)律性與收益開始要求我們?yōu)橹冻龃鷥r。

在sql當(dāng)中，還沒有哪部分組件能像join這樣逼迫開發(fā)人員建立一系列復(fù)雜語句，并承受由此帶來的混亂與絕望。在此之后，存儲引擎還需要找到最優(yōu)方式來高效解壓這些join語句?？偠灾?，這相當(dāng)于開發(fā)人員被迫建立起復(fù)雜的查詢表述，而數(shù)據(jù)庫則被迫對其進(jìn)行梳理。

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

如今磁盤存儲空間已經(jīng)相當(dāng)廉價。市場上已經(jīng)出現(xiàn)了單磁盤8 tb產(chǎn)品，而容量更大的方案也即將亮相。所以相信在不久的將來，我們將徹底告別該當(dāng)活剮的join。

更多信息請查看IT技術(shù)專欄