一,先說一下爲何要分表php
當一張的數據達到幾百萬時,你查詢一次所花的時間會變多,若是有聯合查詢的話,我想有可能會死在那兒了。分表的目的就在於此,減少數據庫的負擔,縮短查詢時間。mysql
根據我的經驗,mysql執行一個sql的過程以下:程序員
一、接收到sql;算法
二、把sql放到排隊隊列中 ;sql
三、執行sql;數據庫
四、返回執行結果。服務器
在這個執行過程當中最花時間在什麼地方呢?第一,是排隊等待的時間;第二,sql的執行時間。其實這二個是一回事,等待的同時,確定有sql在執行。因此咱們要縮短sql的執行時間。測試
mysql中有一種機制是表鎖定和行鎖定,爲何要出現這種機制,是爲了保證數據的完整性。我舉個例子來講吧,若是有兩個sql都要修改同一張表的同一條數據,這個時候怎麼辦呢,是否是兩個sql均可以同時修改這條數據呢?大數據
很顯然mysql對這種狀況的處理是,一種是表鎖定(myisam存儲引擎),一個是行鎖定(innodb存儲引擎)。表鎖定表示大家都不能對這張表進行操做,必須等我對錶操做完才行。行鎖定也同樣,別的sql必須等我對這條數據操做完了,才能對這條數據進行操做。若是數據太多,一次執行的時間太長,等待的時間就越長,這也是咱們爲何要分表的緣由。spa
二,分表
1,作mysql集羣。例如:利用mysql cluster ,mysql proxy,mysql replication,drdb等等
有人會問mysql集羣,和分表有什麼關係嗎?雖然它不是實際意義上的分表,可是它起到了分表的做用。作集羣的意義是什麼呢?爲一個數據庫減輕負擔,說白了就是減小sql排隊隊列中的sql的數量。
舉個例子:有10個sql請求,若是放在一個數據庫服務器的排隊隊列中,他要等很長時間,若是把這10個sql請求,分配到5個數據庫服務器的排隊隊列中,一個數據庫服務器的隊列中只有2個,這樣等待時間是否是大大的縮短了呢?這已經很明顯了。
優勢:擴展性好,沒有多個分表後的複雜操做(php代碼)
缺點:單個表的數據量仍是沒有變,一次操做所花的時間仍是那麼多,硬件開銷大。
2,預先估計會出現大數據量而且訪問頻繁的表,將其分爲若干個表
這種預估大差不差的,論壇裏面發表帖子的表,時間長了這張表確定很大,幾十萬,幾百萬都有可能。 聊天室裏面信息表,幾十我的在一塊兒一聊一個晚上,時間長了,這張表的數據確定很大。像這樣的狀況不少。因此這種能預估出來的大數據量表,咱們就事先分出個N個表,這個N是多少,根據實際狀況而定。以聊天信息表爲例:
我事先建100個這樣的表,message_00,message_01,message_02..........message_98,message_99.而後根據用戶的ID來判斷這個用戶的聊天信息放到哪張表裏面。你能夠用hash的方式來得到,能夠用求餘的方式來得到,方法不少,各人想各人的吧。下面用hash的方法來得到表名:
<?php
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這張表裏,讀取的時候,只要從各自的表中讀取就好了。
優勢:避免一張表出現幾百萬條數據,縮短了一條sql的執行時間
缺點:當一種規則肯定時,打破這條規則會很麻煩,上面的例子中我用的hash算法是crc32,若是我如今不想用這個算法了,改用md5後,會使同一個用戶的消息被存儲到不一樣的表中,這樣數據亂套了。擴展性不好。
3,利用merge存儲引擎來實現分表
我以爲這種方法比較適合,那些沒有事先考慮,而已經出現了的,數據查詢慢的狀況。這個時候若是要把已有的大數據量表分開比較痛苦,最痛苦的事就是改代碼,由於程序裏面的sql語句已經寫好了。如今一張表要分紅幾十張表,甚至上百張表,這樣sql語句是否是要重寫呢?舉個例子,我很喜歡舉子
mysql>show engines;的時候你會發現mrg_myisam其實就是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=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
Query OK, 0 rows affected (0.05 sec)
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=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
Query OK, 0 rows affected (0.01 sec)
mysql> INSERT INTO `user1` (`name`, `sex`) VALUES('張映', 0);
Query OK, 1 row affected (0.00 sec)
mysql> INSERT INTO `user2` (`name`, `sex`) VALUES('tank', 1);
Query OK, 1 row affected (0.00 sec)
mysql> CREATE TABLE IF NOT EXISTS `alluser` (
-> `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 ;
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> select id,name,sex from alluser;
+----+--------+-----+
| id | name | sex |
+----+--------+-----+
| 1 | 張映 | 0 |
| 1 | tank | 1 |
+----+--------+-----+
2 rows in set (0.00 sec)
mysql> INSERT INTO `alluser` (`name`, `sex`) VALUES('tank2', 0);
Query OK, 1 row affected (0.00 sec)
mysql> select id,name,sex from user2
-> ;
+----+-------+-----+
| id | name | sex |
+----+-------+-----+
| 1 | tank | 1 |
| 2 | tank2 | 0 |
+----+-------+-----+
2 rows in set (0.00 sec)
從上面的操做中,我不知道你有沒有發現點什麼?假如我有一張用戶表user,有50W條數據,如今要拆成二張表user1和user2,每張表25W條數據,
INSERT INTO user1(user1.id,user1.name,user1.sex)
SELECT (user.id,user.name,user.sex)FROM user where user.id <= 250000
INSERT INTO user2(user2.id,user2.name,user2.sex)
SELECT (user.id,user.name,user.sex)FROM user where user.id > 250000
這樣我就成功的將一張user表,分紅了二個表,這個時候有一個問題,代碼中的sql語句怎麼辦?之前是一張表,如今變成二張表了,代碼改動很大,這樣給程序員帶來了很大的工做量,有沒有好的辦法解決這一點呢?
辦法是把之前的user表備份一下,而後刪除掉,上面的操做中我創建了一個alluser表,只把這個alluser表的表名改爲user就好了。可是,不是全部的mysql操做都能用的。
a,若是你使用 alter table 來把 merge 表變爲其它表類型,到底層表的映射就被丟失了。取而代之的,來自底層 myisam 表的行被複制到已更換的表中,該表隨後被指定新類型。
b,網上看到一些說replace不起做用,我試了一下能夠起做用的。暈一個先
mysql> UPDATE alluser SET sex=REPLACE(sex, 0, 1) where id=2;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> select * from alluser;
+----+--------+-----+
| id | name | sex |
+----+--------+-----+
| 1 | 張映 | 0 |
| 1 | tank | 1 |
| 2 | tank2 | 1 |
+----+--------+-----+
3 rows in set (0.00 sec)
c,一個 merge 表不能在整個表上維持 unique 約束。當你執行一個 insert,數據進入第一個或者最後一個 myisam 表(取決於 insert_method 選項的值)。mysql 確保惟一鍵值在那個 myisam 表裏保持惟一,但不是跨集合裏全部的表。
d,當你建立一個 merge 表之時,沒有檢查去確保底層表的存在以及有相同的機構。當 merge 表被使用之時,mysql 檢查每一個被映射的表的記錄長度是否相等,但這並不十分可靠。若是你從不類似的 myisam 表建立一個 merge 表,你很是有可能撞見奇怪的問題。
c和d在網上看到的,沒有測試,你們試一下吧。
優勢:擴展性好,而且程序代碼改動的不是很大
缺點:這種方法的效果比第二種要差一點
三,總結一下
上面提到的三種方法,我實際作過二種,第一種和第二種。第三種沒有作過,因此說的細一點。哈哈。作什麼事都有一個度,超過個度就過變得不好,不能一味的作數據庫服務器集羣,硬件是要花錢買的。也不要一味的分表,分出來1000表,mysql的存儲歸根到底還以文件的形勢存在硬盤上面,一張表對應三個文件,1000個分表就是對應3000個文件,這樣檢索起來也會變的很慢。個人建議是:
方法1和方法2結合的方式來進行分表
方法1和方法3結合的方式來進行分表
個人二個建議適合不一樣的狀況,根據我的狀況而定,我以爲會有不少人選擇方法1和方法3結合的方式。