分表
1,做mysql集群,例如:利用mysql cluster ,mysql proxy,mysql replication,drdb等等
有人會問mysql集群,根分表有什麼關系嗎?雖然它不是實際意義上的分表,但是它啟到了分表的作用,做集群的意義是什麼呢?為一個數據庫減輕負擔,說白了就是減少sql排隊隊列中的sql的數量,舉個例子:有10個sql請求,如果放在一個數據庫服務器的排隊隊列中,他要等很長時間,如果把這10個sql請求,分配到5個數據庫服務器的排隊隊列中,一個數據庫服務器的隊列中只有2個,這樣等待時間是不是大大的縮短了呢?這已經很明顯了。所以我把它列到了分表的范圍以內,我做過一些mysql的集群:
linux mysql proxy 的安裝,配置,以及讀寫分離
mysql replication 互為主從的安裝及配置,以及數據同步
優點:擴展性好,沒有多個分表後的復雜操作(php代碼)
缺點:單個表的數據量還是沒有變,一次操作所花的時間還是那麼多,硬件開銷大。
2,預先估計會出現大數據量並且訪問頻繁的表,將其分為若干個表
這種預估大差不差的,論壇裡面發表帖子的表,時間長了這張表肯定很大,幾十萬,幾百萬都有可能。 聊天室裡面信息表,幾十個人在一起一聊一個晚上,時間長了,這張表的數據肯定很大。像這樣的情況很多。所以這種能預估出來的大數據量表,我們就事先分出個N個表,這個N是多少,根據實際情況而定。以聊天信息表為例:
我事先建100個這樣的表,message_00,message_01,message_02……….message_98,message_99.然後根據用戶的ID來判斷這個用戶的聊天信息放到哪張表裡面,你可以用hash的方式來獲得,可以用求余的方式來獲得,方法很多,各人想各人的吧。下面用hash的方法來獲得表名:
查看復制打印?
說明一下,上面的這個方法,告訴我們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` (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這樣我就成功的將一張user表,分成了二個表,這個時候有一個問題,代碼中的sql語句怎麼辦,以前是一張表,現在變成二張表了,代碼改動很大,這樣給程序員帶來了很大的工作量,有沒有好的辦法解決這一點呢?辦法是把以前的user表備份一下,然後刪除掉,上面的操作中我建立了一個alluser表,只把這個alluser表的表名改成user就行了。但是,不是所有的mysql操作都能用的
a,如果你使用 alter table 來把 merge 表變為其它表類型,到底層表的映射就被丟失了。取而代之的,來自底層 myisam 表的行被復制到已更換的表中,該表隨後被指定新類型。
b,網上看到一些說replace不起作用,我試了一下可以起作用的。暈一個先
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結合的方式