眾所鄒知，數(shù)據(jù)庫的無論是在設(shè)計(jì)過程中，還是在使用過程中，都存在一些小技巧和方法。因此，經(jīng)常使用數(shù)據(jù)庫的人都會(huì)總結(jié)這些方法。本文要總結(jié)的方法是：數(shù)據(jù)庫水平切分的方法有哪些？數(shù)據(jù)庫字段設(shè)計(jì)方法有哪些？關(guān)于數(shù)據(jù)庫水平切分的方法有兩個(gè)，而對(duì)于數(shù)據(jù)庫字段的設(shè)計(jì)方法這里總結(jié)了12點(diǎn)，下文是詳解。

　　數(shù)據(jù)庫水平切分的方法有哪些？

　　方法一：使用MD5哈希

做法是對(duì)UID進(jìn)行md5加密，然后取前幾位（我們這里取前兩位），然后就可以將不同的UID哈希到不同的用戶表（user_xx）中了。

function getTable( $uid ){

$ext = substr ( md5($uid) ,0 ,2 );

return "user_".$ext;

}

通過這個(gè)技巧，我們可以將不同的UID分散到256中用戶表中，分別是user_00,user_01 ...... user_ff。因?yàn)閁ID是數(shù)字且遞增，根據(jù)md5的算法，可以將用戶數(shù)據(jù)幾乎很均勻的分別到不同的user表中。

但是這里有個(gè)問題是，如果我們的系統(tǒng)的用戶越來越多，勢(shì)必單張表的數(shù)據(jù)量越來越大，而且根據(jù)這種算法無法擴(kuò)展表，這又會(huì)回到文章開頭出現(xiàn)的問題了。

方法二：使用移位

具體方法是：

public function getTable( $uid ) {

return "user_" . sprintf( "%04d", ($uid >> 20) );

}

這里，我們將uid向右移動(dòng)20位，這樣我們就可以把大約前100萬的用戶數(shù)據(jù)放在第一個(gè)表user_0000,第二個(gè)100萬的用戶數(shù)據(jù)放在第二個(gè)表user_0001中，這樣一直下去，如果我們的用戶越來越多，直接添加用戶表就行了。由于我們保留的表后綴是四位，這里我們可以添加1萬張用戶表，即user_0000,user_0001 ...... user_9999。一萬張表，每張表100萬數(shù)據(jù)，我們可以存100億條用戶記錄。當(dāng)然，如果你的用戶數(shù)據(jù)比這還多，也不要緊，你只要改變保留表后綴來增加可以擴(kuò)展的表就行了，如如果有1000億條數(shù)據(jù)，每個(gè)表存100萬，那么你需要10萬張表，我們只要保留表后綴為6位即可。

上面的算法還可以寫的靈活點(diǎn)：

/**

* 根據(jù)UID分表算法

*

* @param int $uid //用戶ID

* @param int $bit //表后綴保留幾位

* @param int $seed //向右移動(dòng)位數(shù)

*/

function getTable( $uid , $bit , $seed ){

return "user_" . sprintf( "%0{$bit}d" , ($uid >> $seed) );

}

上面兩種方法，都要對(duì)我們當(dāng)前系統(tǒng)的用戶數(shù)據(jù)量做出可能最大的預(yù)估，并且對(duì)數(shù)據(jù)庫單個(gè)表的最大承受量做出預(yù)估。

比如第二種方案，如果我們預(yù)估我們系統(tǒng)的用戶是100億，單張表的最優(yōu)數(shù)據(jù)量是100萬，那么我們就需要將UID移動(dòng)20來確保每個(gè)表是100萬的數(shù)據(jù)，保留用戶表（user_xxxx）四位來擴(kuò)展1萬張表。

又如第一種方案，每張表100萬，md5后取前兩位，就只能有256張表了，系統(tǒng)總數(shù)據(jù)庫就是：256*100萬；如果你系統(tǒng)的總數(shù)據(jù)量的比這還多，那你實(shí)現(xiàn)肯定要MD5取前三位或者四位甚至更多位了。

兩種方法都是將數(shù)據(jù)水平切分到不同的表中，相對(duì)第一種方法，第二種方法更具擴(kuò)展性。

　　數(shù)據(jù)庫字段設(shè)計(jì)方法有哪些？

1. tinyint 是-128到128 。當(dāng)屬性設(shè)置為unsigned的時(shí)候。最大值就是255了。現(xiàn)在知道為什么需要設(shè)置為unsigned屬性了。原來是為了最大限度的使用給予的存儲(chǔ)空間。如果不設(shè)置。那么假如你的值都是正數(shù)的。那么-128這一百多個(gè)數(shù)字就相當(dāng)于是浪費(fèi)了。

2. tinyint會(huì)自動(dòng)設(shè)置為tinyint（3）。

3. smallint 不設(shè)置unsigned的時(shí)候，也有3萬多的樣子。

4. tinytext 就是255個(gè)字節(jié)。大概就是存儲(chǔ)127個(gè)中文的樣子 tinytext就相當(dāng)于varchar類型。把它看成這樣的該類型就容易理解了。

5. int 類型phpmyadmin默認(rèn)會(huì)設(shè)置int（10）。

6. 概念糾正：原來一直以為這里的10表示位數(shù)。直到有次想保存1101061021496，結(jié)果在字段中的值都變成了：4294967295。 看MySQL手冊(cè)上說：

（int后面括號(hào)的數(shù)字）顯示寬度并不限制可以在列內(nèi)保存的值的范圍，也不限制超過列的指定寬度的值的顯示。

7. int的范圍：-2147483648到2147483647。剛好是10個(gè)位，那么就是數(shù)十億級(jí)別的數(shù)字。數(shù)據(jù)庫設(shè)計(jì)經(jīng)驗(yàn)：像訂單的值非常大。不確定，如果達(dá)到10位數(shù)，還不如使用varchar類型。fangwei就沒有使用int，而是varchar類型。

8. 從上面也告訴我一個(gè)經(jīng)驗(yàn)：如果保存在數(shù)據(jù)庫的值都變成一樣的。也就是無論我是1101061021496 還是1101061021569，結(jié)果都變成了固定的值，比如4294967295。那么可以考慮確認(rèn)是否是數(shù)據(jù)庫該字段的范圍問題。這樣的問題出現(xiàn)過好幾次了。就是沒有掌握思路。導(dǎo)致浪費(fèi)了不少時(shí)間。

9. 將字段設(shè)置為not null 還出于另外一種考慮：mysql表的列中包含null的話，那么該列不會(huì)包含在所有中。也就是使用索引是無效的。所有，考慮今后會(huì)使用索引的字段，就要設(shè)置字段屬性是not null。

10. 如果你要保存NULL，手動(dòng)去設(shè)置它，而不是把它設(shè)為默認(rèn)值。

11. 考慮到這個(gè)字段今后會(huì)作為查詢關(guān)鍵字使用like的形式進(jìn)行搜索。那么要將該字段定義成索引。這樣使用like查詢就會(huì)更快。

12. 現(xiàn)在終于體會(huì)到到國(guó)外作者書籍上提到：設(shè)計(jì)數(shù)據(jù)庫之前要問自己，之后會(huì)查詢哪些數(shù)據(jù)。 考慮了這些，以后有什么查詢需要。結(jié)構(gòu)都能適應(yīng)了。

上述就是關(guān)于數(shù)據(jù)庫水平切分的方法有哪些，以及數(shù)據(jù)庫字段設(shè)計(jì)方法有哪些的全部?jī)?nèi)容，想了解更多關(guān)于數(shù)據(jù)庫的信息，請(qǐng)繼續(xù)關(guān)注中培偉業(yè)。