這篇文章如題所述，只打算談一下數(shù)據(jù)庫表本身設(shè)計(jì)，同時(shí)講到和表結(jié)構(gòu)相關(guān)的性能和擴(kuò)展性問題。下面講到的東西大多是從實(shí)際經(jīng)驗(yàn)中總結(jié)而來，算是對(duì)這項(xiàng)技術(shù)的一個(gè)反思。

基本上在設(shè)計(jì)數(shù)據(jù)庫表的時(shí)候，首先考慮設(shè)計(jì)要滿足功能需求，這是最根本的，其次是滿足性能需求，再次則是滿足擴(kuò)展性需求，這一點(diǎn)在大規(guī)模系統(tǒng)中是必須要考慮的。功能性需求比較容易滿足，下面我主要談?wù)剬?duì)性能和擴(kuò)展性需求的一些設(shè)計(jì)方法。

沒人不想速度更快，但是怎樣才能更快呢。設(shè)計(jì)高性能的表，我認(rèn)為主要需要做好：設(shè)計(jì)精簡合理的結(jié)構(gòu)、減小數(shù)據(jù)量，具體的做法下面逐個(gè)分析。

合理利用字段類型和長度。字段類型盡可能反映真實(shí)的數(shù)據(jù)含義，滿足功能外字段應(yīng)該盡可能的短。 比如能用int字段的就不要用bigint，如果在某一個(gè)關(guān)系表里只有兩個(gè)id字段，那么bigint類型顯然比int類型的大了一倍。不同的數(shù)據(jù)庫系統(tǒng)里面varchar和text類型在數(shù)據(jù)長度限制上不一樣，性能上也不一樣，選取要謹(jǐn)慎。標(biāo)記位字段如果有bit就用bit類型，否則就用byte，用int就很浪費(fèi)了（下面有一種特例）。

選取高效的主鍵和索引。關(guān)于主鍵的選取，特別需要注意，因?yàn)閷?duì)表中數(shù)據(jù)的讀取都直接或間接通過

主鍵，所以應(yīng)該根據(jù)應(yīng)用的特性設(shè)計(jì)滿足最接近數(shù)據(jù)存取順序的主鍵。例如數(shù)據(jù)讀取按照r1、r2、r3的順序，那么他們的主鍵也最好是1、2、3的順序。有些人喜歡在關(guān)系表里面也另外加一個(gè)主鍵字段，我認(rèn)為這樣算是浪費(fèi)空間，而用關(guān)系ID作聯(lián)合主見更合理。

索引的大小基本上由字段來決定，所以需要建立索引的字段應(yīng)該簡化到最小。但是有些字段必須建立索引卻又無法簡化，這時(shí)候可以考慮用hash算法計(jì)算出較小的值作為索引。例如url字段不適合做索引，但是可以用一個(gè)url_md5字段來存儲(chǔ)url的md5值來作為索引，有效降低鍵值長度。

減小數(shù)據(jù)量。除了縮小字段長度減小數(shù)據(jù)外，數(shù)據(jù)壓縮也是一個(gè)行之有效的辦法。目前有些數(shù)據(jù)庫引擎支持自動(dòng)壓縮，相當(dāng)方便，否則的自行通過程序壓縮、解壓也是可行的方案，壓縮對(duì)較長的文章、帖子性能提升顯著。壓縮還需要注意的一點(diǎn)就是內(nèi)容太短，壓縮只會(huì)增加長度，壓縮過的內(nèi)容無法再壓縮。

精簡表結(jié)構(gòu)。一個(gè)表復(fù)雜了不光處理起來更麻煩，而其性能也不好。如果一個(gè)表里面有多部分（幾個(gè)字段合起來為一部分）的字段并不同時(shí)存取，那么這多部分字段應(yīng)該根據(jù)存取特性分開為多個(gè)表，這樣避免并發(fā)操作的鎖競(jìng)爭(zhēng)。如果實(shí)在無法再分并且還是字段眾多，那么可以把描述同一個(gè)對(duì)象的字段合并成一個(gè)字段存儲(chǔ)，有效降低字段數(shù)目，如果空字段較多時(shí)，這樣更能節(jié)省資源。例如，在customer表里面company_name，company_phone等字段可以合并為company字段，當(dāng)然這樣做的前提是company_name字段不需要單獨(dú)作為查詢條件（如果使用數(shù)據(jù)庫的xml技術(shù)，conpmay_name也可以作為查詢條件）。

適當(dāng)采用冗余字段，其實(shí)在我設(shè)計(jì)大部分表里面是沒有冗余字段的，并不是說冗余字段不好，而是目前通過緩存系統(tǒng)可以適當(dāng)代替冗余字段的好處。冗余字段主要是為了避免多次關(guān)聯(lián)的查詢，但是如果關(guān)聯(lián)數(shù)據(jù)很容易被緩存，那么查詢出主要數(shù)據(jù)后，關(guān)聯(lián)數(shù)據(jù)直接從緩存中讀取，這樣冗余字段方案就可以被替代了。但是在緩存不利的情況下，冗余字段確實(shí)是提升性能行之有效的辦法。

其實(shí)影響數(shù)據(jù)庫性能的還有包括磁盤IO、內(nèi)存、數(shù)據(jù)庫鎖、系統(tǒng)配置、數(shù)據(jù)庫配置、CPU性能等其他因素，但是這些并不在本文范疇。在大規(guī)模系統(tǒng)中，除了性能，可擴(kuò)展性也是設(shè)計(jì)的關(guān)鍵字點(diǎn)，而數(shù)據(jù)庫表擴(kuò)展性主要包含表邏輯結(jié)構(gòu)、功能字段的增加、分表等。

對(duì)于表的邏輯結(jié)構(gòu)我遵循的設(shè)計(jì)原則：一個(gè)表只包含一個(gè)主要實(shí)體，如果主要實(shí)體中包含從屬實(shí)體數(shù)據(jù)，并且多個(gè)主要實(shí)體共享一個(gè)從屬實(shí)體，則把從屬實(shí)體單獨(dú)設(shè)計(jì)為表，與主要實(shí)體關(guān)聯(lián)，這樣增加一個(gè)從屬實(shí)體增加單獨(dú)的表就行，不會(huì)影響以前的功能。如果主要實(shí)體不共享從屬實(shí)體，把從屬實(shí)體多個(gè)字段打包合并為一個(gè)字段。合并字段的方式在上面也有提及，它不僅減少字段數(shù)目，而且讓在合并的字段中增加數(shù)據(jù)字段變得非常容易。

在數(shù)據(jù)庫里面經(jīng)常用到標(biāo)記位字段，取值只有0/1（true/false），有時(shí)候一個(gè)表里有很多這樣的字段，這種情況下我認(rèn)為把所有標(biāo)記為字段合并到一個(gè)數(shù)字字段更好，數(shù)字中的每一位就表示一個(gè)標(biāo)記位，例如用一個(gè)int型字段可以表示32個(gè)標(biāo)記位。這可能帶來一些使用上的不便，不過卻大大增加了可擴(kuò)展性。例如當(dāng)16個(gè)標(biāo)記位字段合并到int型字段后，還留下了16位的擴(kuò)展余地。并且用byte、int還是bigint可以隨取所需。

增加表字段，好像也并不是難事，一條SQL而已。但是如果在Mysql里面，修改表結(jié)構(gòu)后引擎會(huì)導(dǎo)出再導(dǎo)入數(shù)據(jù)，在大數(shù)據(jù)量下（比如1000w、1億）增加字段變得幾乎不可能。對(duì)于這個(gè)問題，有人喜歡提前在表里面多加一到多個(gè)保留字段，我個(gè)人比較反對(duì)這樣的做法：一是擴(kuò)展性有限、二是命名太奇怪、三是類型不一定合適。我的設(shè)計(jì)原則：小表（比如50w行、100MB數(shù)據(jù)以內(nèi)的表）不用特別考慮此擴(kuò)展性問題，設(shè)計(jì)時(shí)只需要設(shè)計(jì)符合當(dāng)前需求就可以，因?yàn)榧词挂院髮?duì)結(jié)構(gòu)修改，也可以在很快的時(shí)間內(nèi)完成。關(guān)系表等結(jié)構(gòu)很穩(wěn)定的表也不用考慮此問題。復(fù)雜的大表里，首先確定核心的業(yè)務(wù)實(shí)體字段、外鍵和索引，而其他的字段則根據(jù)情況包合并到一個(gè)extra（xml或者字符串類型）的字段里，這樣也就可以滿足了以后的擴(kuò)展需求，因?yàn)樽址蛘選ml結(jié)構(gòu)里增加數(shù)據(jù)字段是很容易的事情。

分表（非分區(qū)，分區(qū)后并不會(huì)產(chǎn)生多個(gè)表，在部署上和分表會(huì)有不同，并非所有的數(shù)據(jù)庫版本都支持），也就是對(duì)表垂直切分，得到結(jié)構(gòu)相同的多個(gè)小表，是提升大表性能的首選方案。分表最基本的方法就是，固定法：根據(jù)ID特性把表拆分成固定的N個(gè)表、動(dòng)態(tài)增長法：根據(jù)ID值分成等值區(qū)間任意多表、外鍵劃分法：根據(jù)外鍵值得特性劃分。如果ID增長沒有規(guī)律，那么分表可采用固定法，基本算法為：用ID對(duì)N取模或者獲取HASH（ID）的某部分字符串作為表名的一部分。如果ID連續(xù)變化，則采用而動(dòng)態(tài)增長法，基本算法為：測(cè)試單表最合理的數(shù)據(jù)行數(shù)N，然后根據(jù)N作為區(qū)間長度對(duì)ID拆分，拆分結(jié)果為1-N，N+1-2N…。外鍵劃分法是根據(jù)外鍵值對(duì)表進(jìn)行劃分，基本的方法也就是固定法和動(dòng)態(tài)增長法。不同的分表方法是由數(shù)據(jù)的特性和數(shù)據(jù)之間的關(guān)系決定的，例如需要根據(jù)URL查詢到文章，由于URL是無規(guī)律的，那么分表方法可以為固定法，按照URL的MD5值對(duì)表進(jìn)行劃分。例如論壇的帖子可以按照論壇板塊ID來分表，每個(gè)板塊一個(gè)表多個(gè)板塊一個(gè)表，這是外鍵劃分法。如果論壇和帖子是多對(duì)多關(guān)系，那么帖子可以采用動(dòng)態(tài)增長法分表，然后再把帖子和板塊關(guān)系表采用外鍵劃分法來分。這里描述的方法算是比較基本的方法，而真實(shí)系統(tǒng)中分表情況要復(fù)雜的多，例如用戶表里如果根據(jù)ID分表，但是又需要根據(jù)Email/密碼登錄，如果有10個(gè)用戶表，登錄操作顯然是很昂貴的，怎么辦呢？分表，不是簡單的事情。