MySQL分表一般分為兩種：垂直分表和水平分表，兩種方法各有優(yōu)點，需要根據(jù)具體情況去選擇。

一、垂直分表

把原來有很多列的表拆分成多個表，原則是：

（1）把常用、不常用的字段分開放

（2）把大字段獨立存放在一個表中

二、水平分表

為了解決單表數(shù)據(jù)量過大的問題，每個水平拆分表的結(jié)構(gòu)完全一致

2.1 按時間結(jié)構(gòu)

如果業(yè)務系統(tǒng)對時效性較高，比如新聞發(fā)布系統(tǒng)的文章表，可以把數(shù)據(jù)庫設計成時間結(jié)構(gòu)，按時間分有下面幾種結(jié)構(gòu)

2.1.1 平板式

article_201701 article_201702 article_201703

用年來分還是用月可自定，但用日期的話表就太多了，也沒這必要。一般建議是按月分就可以。

這種分法，其難處在于，假設我要列20條數(shù)據(jù)，結(jié)果這三張表里都有2條，那么業(yè)務上很有可能要求讀三次表。如果時間長了，有幾十張表，而每張表是0條，那不就是要讀完整個系統(tǒng)的表才行么?另外這個結(jié)構(gòu)，要作分頁是比較難實現(xiàn)的。

主鍵：在這個系統(tǒng)中，主鍵是13位帶毫秒的時間戳，不要用自動編號，否則難以通過主鍵定位到表，也可以在查詢時帶上時間，但比較煩瑣。

2.1.2 歸檔式

article_old article_new

為了解決平板式的缺點，可以采用時間歸檔式設計，可以看到這個系統(tǒng)只有兩張表。一張是舊文章表，一張是新文章表，新文章表放2個月的信息，每天定期把2個月中的最早一天的文章歸入舊表中。這樣一方面可以解決性能問題，因為一般新聞發(fā)布系統(tǒng)讀取的都是新的內(nèi)容，舊的內(nèi)容讀取少;第二可以委婉地解決功能問題，比如平板式所說的問題，在歸檔式中最多也只需要讀2張表就完成了。

歸檔式的缺點在于舊表容量還是相對比較大，如果業(yè)務允許，可對舊表中的超舊內(nèi)容進行再歸檔或直接清理掉。

2.2 按版塊結(jié)構(gòu)

如果按照文章的所屬版塊進行拆表，比如新聞、體育版塊拆表，一方面可以使每個表數(shù)據(jù)量分離，另一方面是各版塊之間相互影響可降到最低。假如新聞版塊的數(shù)據(jù)表損壞或需要維護，并不會影響到體育版塊的正常工作，從而降低了風險。版塊結(jié)構(gòu)同時常用于bbs這樣的系統(tǒng)。

板塊結(jié)構(gòu)也有如下幾種分法

2.2.1 對應式

對于版塊數(shù)量不多，而且較為固定的形式，就直接對應就好。比如新聞版塊，可以分出新聞的目錄表，新聞的文章表等。

news_category news_article sports_category sports_article

可看到每一個版塊都對應著一組相同的表結(jié)構(gòu)，好處就是一目了然。在功能上，因為版塊之間還是有一些隔閡，所以需要聯(lián)合查詢的需求不多，開發(fā)上比時間結(jié)構(gòu)的方式要輕松。

主鍵：依舊要考慮的，在這個系統(tǒng)中，主鍵是版塊+時間戳，單純的時間戳或自動編號也能用，查詢時要記得帶上版塊用于定位表。

2.2.2 冷熱式

對應式的缺點是，如果版塊數(shù)量很大而且不確定，那要分出的表數(shù)量就太多了。舉個例子：百度貼吧，如果按一個詞條一個表設計，那得有多少張表呢?

用這樣的方式吧。

tieba_汽車 tieba_飛機 tieba_火箭 tieba_unite

這個表汽車、火箭表是屬于熱門表，定義為新建的版塊放在unite表里面，待到其超過一萬張主貼的時候才開對應表結(jié)構(gòu)。因為在貼吧這種系統(tǒng)中，冷門版塊

肯定比熱門版塊多得多，這些冷門版塊通常只有幾張?zhí)樱瑸樗鼈冮_表也太浪費了;同時熱門版塊數(shù)量和訪問量等，又比冷門版塊多得多，非常有特點。

unite表還可以擴展成哈希表，利用詞條的md5編碼，可以分成n張表，我算了一下，md5前一位可分36張表，兩位即是1296張表，足夠了。

tieba_unite_ab tieba_unite_ac

2.3 按哈希結(jié)構(gòu)

哈希結(jié)構(gòu)通常用于博客之類的基于用戶的場合，在博客這樣的系統(tǒng)里有幾個特點，

• 是用戶數(shù)量非常多，

• 是每個用戶發(fā)的文章數(shù)量都較少，

• 是用戶發(fā)文章不定期，

• 是每個用戶發(fā)得不多，但總量仍非常之大。

基于這些特點，用以上所說的任何一種分表方式都不合適，一沒有固定的時效不宜用時間拆，二用戶很多，而且還偏偏都是冷門，所以也不宜用版塊(用戶)拆。

哈希結(jié)構(gòu)在上面有所提及，既然按每個用戶不好直接拆，那就把一群用戶歸進一個表好了。

blog_aa blog_ab blog_ac

如上所說，md5取前兩位哈?？梢赃_到1296張表，如果覺得不夠，那就再加一位，總數(shù)可達46656張表，還不夠?

表的數(shù)量太多，要創(chuàng)建這些表也是挺麻煩的，可以考慮在程序里往數(shù)據(jù)庫insert之前，多執(zhí)行一句判斷表存在與否并創(chuàng)建表的語句，很實用，消耗也并不很大。

主鍵：依舊要考慮的，在這個系統(tǒng)中，主鍵是用戶ID+時間戳，單純的時間戳或自動編號也能用，但查詢時要記得帶上用戶名用于定位表。

最后送大家一份 JetBrains IDEA 破解教程和干貨，快拿去用吧：

百度網(wǎng)盤鏈接：https://pan.baidu.com/s/1jxvnKgTsTbkVmjcPGeTm0g

提取碼：2cg8?