根據(jù)經(jīng)驗，Mysql表數(shù)據(jù)一般達到百萬級別，查詢效率會很低，容易造成表鎖，甚至堆積很多連接，直接掛掉；水平分表能夠很大程度較少這些壓力。
這種分表方式有一定的局限性，當數(shù)據(jù)有較強的實效性，如微博發(fā)送記錄、微信消息記錄等，這種數(shù)據(jù)很少有用戶會查詢幾個月前的數(shù)據(jù)，如就可以按月分表。
一般在有嚴格的自增id需求上，如按照user_id水平分表：
table_1 ?user_id從1~100w
table_2 ?user_id從101~200w
table_3 ?user_id從201~300w
...
通過一個原始目標的ID或者名稱通過一定的hash算法計算出數(shù)據(jù)存儲表的表名，然后訪問相應的表。
按如下分10張表：
functionget_hash_table($table,$userid)
{
$str=crc32($userid);
if($str<0){
$hash="0".substr(abs($str),0,1);
}else{
$hash=substr($str,0,2);
}
return$table."_".$hash;
}
echo get_hash_table('message','user18991');//結果為message_10
echo get_hash_table('message','user34523');//結果為message_13
另外，介紹我現(xiàn)在就是采用簡單的取模分表：
/**
* @param string $table_name 表名
* @param int $user_id 用戶id
* @param int $total 分表總數(shù)
* @link http://www.phpddt.com
*/
functionhash_table($table_name,$user_id,$total)
{
return$table_name.'_'.(($user_id%$total)+1);
}
echo hash_table("artice",1234,5);//artice_5
echo hash_table("artice",3243,5);//artice_4
感覺merge存儲引擎類似sql中union的感覺，但是查詢效率不高。
如下舉例，擁有1000w記錄的old_user表分表：
（1）創(chuàng)建new_user表使用merge存儲引擎
mysql>CREATE TABLE IF NOT EXISTS`user1`(
->`id`int(11)NOT NULL AUTO_INCREMENT,
->`name`varchar(50)DEFAULT NULL,
->`sex`int(1)NOT NULL DEFAULT'0',
->PRIMARY KEY(`id`)
->)ENGINE=MyISAMDEFAULT CHARSET=utf8 AUTO_INCREMENT=1;
QueryOK,0rows affected(0.05sec)
mysql>CREATE TABLE IF NOT EXISTS`user2`(
->`id`int(11)NOT NULL AUTO_INCREMENT,
->`name`varchar(50)DEFAULT NULL,
->`sex`int(1)NOT NULL DEFAULT'0',
->PRIMARY KEY(`id`)
->)ENGINE=MyISAMDEFAULT CHARSET=utf8 AUTO_INCREMENT=1;
QueryOK,0rows affected(0.01sec)
mysql>INSERT INTO`user1`(`name`,`sex`)VALUES('張映',0);
QueryOK,1row affected(0.00sec)
mysql>INSERT INTO`user2`(`name`,`sex`)VALUES('tank',1);
QueryOK,1row affected(0.00sec)
mysql>CREATE TABLE IF NOT EXISTS`new_user`(
->`id`int(11)NOT NULL AUTO_INCREMENT,
->`name`varchar(50)DEFAULT NULL,
->`sex`int(1)NOT NULL DEFAULT'0',
->INDEX(id)
->)TYPE=MERGE UNION=(user1,user2)INSERT_METHOD=LAST AUTO_INCREMENT=1;
QueryOK,0rows affected,1warning(0.00sec)
mysql>selectid,name,sexfromnew_user;
+----+--------+-----+
|id|name|sex|
+----+--------+-----+
|1|張映|0|
|1|tank|1|
+----+--------+-----+
2rowsinset(0.00sec)
mysql>INSERT INTO`new_user`(`name`,`sex`)VALUES('tank2',0);
QueryOK,1row affected(0.00sec)
mysql>selectid,name,sexfromuser2
->;
+----+-------+-----+
|id|name|sex|
+----+-------+-----+
|1|tank|1|
|2|tank2|0|
+----+-------+-----+
2rowsinset(0.00sec)
（2）我old_user數(shù)據(jù)進行分表：
INSERT INTO user1(user1.id,user1.name,user1.sex)SELECT(user.id,user.name,user.sex)FROM old_userwhereuser.id<=5000000
INSERT INTO user2(user2.id,user2.name,user2.sex)SELECT(user.id,user.name,user.sex)FROM old_userwhereuser.id>10000000
1，做mysql集群，例如：利用mysql cluster ，mysql proxy，mysql replication，drdb等等
有人會問mysql集群，根分表有什么關系嗎？雖然它不是實際意義上的分表，但是它啟到了分表的作用，做集群的意義是什么呢？為一個數(shù)據(jù)庫減輕負擔，說白了就是減少sql排隊隊列中的sql的數(shù)量，舉個例子：有10個sql請求，如果放在一個數(shù)據(jù)庫服務器的排隊隊列中，他要等很長時間，如果把這10個sql請求，分配到5個數(shù)據(jù)庫服務器的排隊隊列中，一個數(shù)據(jù)庫服務器的隊列中只有2個，這樣等待時間是不是大大的縮短了呢？這已經(jīng)很明顯了。所以我把它列到了分表的范圍以內，我做過一些mysql的集群：
linux mysql proxy 的安裝，配置，以及讀寫分離
mysql replication 互為主從的安裝及配置，以及數(shù)據(jù)同步
優(yōu)點：擴展性好，沒有多個分表后的復雜操作（php代碼）
缺點：單個表的數(shù)據(jù)量還是沒有變，一次操作所花的時間還是那么多，硬件開銷大。
2，預先估計會出現(xiàn)大數(shù)據(jù)量并且訪問頻繁的表，將其分為若干個表
這種預估大差不差的，論壇里面發(fā)表帖子的表，時間長了這張表肯定很大，幾十萬，幾百萬都有可能。
聊天室里面信息表，幾十個人在一起一聊一個晚上，時間長了，這張表的數(shù)據(jù)肯定很大。像這樣的情況很多。所以這種能預估出來的大數(shù)據(jù)量表，我們就事先分出個N個表，這個N是多少，根據(jù)實際情況而定。以聊天信息表為例：
我事先建100個這樣的表，message_00,message_01,message_02……….message_98,message_99.然后根據(jù)用戶的ID來判斷這個用戶的聊天信息放到哪張表里面，你可以用hash的方式來獲得，可以用求余的方式來獲得，方法很多，各人想各人的吧。下面用hash的方法來獲得表名：
復制代碼代碼如下:
function get_hash_table($table,$userid) {
$str = crc32($userid);
if($str<0){
$hash = "0".substr(abs($str), 0, 1);
}else{
$hash = substr($str, 0, 2);
}
return $table."_".$hash;
}
echo get_hash_table('message' , 'user18991');???? //結果為message_10
echo get_hash_table('message' , 'user34523');??? //結果為message_13
?>
說明一下，上面的這個方法，告訴我們user18991這個用戶的消息都記錄在message_10這張表里，user34523這個用戶的消息都記錄在message_13這張表里，讀取的時候，只要從各自的表中讀取就行了。
優(yōu)點：避免一張表出現(xiàn)幾百萬條數(shù)據(jù)，縮短了一條sql的執(zhí)行時間
缺點：當一種規(guī)則確定時，打破這條規(guī)則會很麻煩，上面的例子中我用的hash算法是crc32，如果我現(xiàn)在不想用這個算法了，改用md5后，會使同一個用戶的消息被存儲到不同的表中，這樣數(shù)據(jù)亂套了。擴展性很差。
