一、時間結構
1) 平板式
表類似：
article_200901
article_200902
article_200903
用年來分還是用月可自定，但用日期的話表就太多了，也沒這必要。一般建議是按月分就可以。
這種分法，其難處在於，假設我要列20條資料，結果這三張表裡都有2條，那麼業務上很有可能要求讀三次表。如果時間長了，有幾十張表，而每張表是0條，那不就是要讀完整個系統的表才行麼?另外這個結構，要作分頁是比較難實現的。
主鍵：在這個系統中，主鍵是13位帶毫秒的時間戳，不要用自動編號，否則難以通過主鍵定位到表，也可以在查詢時帶上時間，但比較煩瑣。
2) 歸檔式
表類似：
article_old
article_new
為了解決平板式的缺點，可以採用時間歸檔式設計，可以看到這個系統只有兩張表。一張是舊文章表，一張是新文章表，新文章表放2個月的資訊，每天定期把2個月中的最早一天的文章歸入舊表中。這樣一方面可以解決效能問題，因為一般新聞發布系統讀取的都是新的內容，舊的內容讀取少;第二可以委婉地解決功能問題，比如平板式所說的問題，在歸檔式中最多也只需要讀2張表就完成了。
歸檔式的缺點在於舊表容量還是相對比較大，如果業務允許，可對舊表中的超舊內容進行再歸檔或直接清理掉。
二、版塊結構
如果按照文章的所屬版塊進行拆表，比如新聞、體育版塊拆表，一方面可以使每個表資料量分離，另一方面是各版塊之間相互影響可降到最低。假如新聞版塊的資料表損壞或需要維護，並不會影響到體育版塊的正常工作，從而降低了風險。版塊結構同時常用於bbs這樣的系統。
板塊結構也有幾種分法：
1) 對應式
對於版塊數量不多，而且較為固定的形式，就直接對應就好。比如新聞版塊，可以分出新聞的目錄表，新聞的文章表等。
news_category
news_article
sports_category
sports_article
可看到每乙個版塊都對應著一組相同的表結構，好處就是一目了然。在功能上，因為版塊之間還是有一些隔閡，所以需要聯合查詢的需求不多，開發上比時間結構的方式要輕鬆。
主鍵：依舊要考慮的，在這個系統中，主鍵是版塊+時間戳，單純的時間戳或自動編號也能用，查詢時要記得帶上版塊用於定位表。
2) 冷熱式
用這樣的方式吧。
tieba_汽車
tieba_飛機
tieba_火箭
tieba__unite
這個表汽車、火箭表是屬於熱門表，定義為新建的版塊放在unite表裡面，待到其超過一萬張主貼的時候才開對應表結構。因為在貼吧這種系統中，冷門版塊肯定比熱門版塊多得多，這些冷門版塊通常只有幾張帖子，為它們開表也太浪費了;同時熱門版塊數量和訪問量等，又比冷門版塊多得多，非常有特點。
unite表還可以擴充套件成雜湊表，利用詞條的md5編碼，可以分成n張表，我算了一下，md5前一位可分36張表，兩位即是1296張表，足夠了。
tieba_unite_ab
tieba_unite_ac
三、雜湊結構
雜湊結構通常用於部落格之類的基於使用者的場合，在部落格這樣的系統裡有幾個特點，1是使用者數量非常多，2是每個使用者發的文章數量都較少，3是使用者發文章不定期，4是每個使用者發得不多，但總量仍非常之大。基於這些特點，用以上所說的任何一種分表方式都不合適，一沒有固定的時效不宜用時間拆，二使用者很多，而且還偏偏都是冷門，所以也不宜用版塊(使用者)拆。
雜湊結構在上面有所提及，既然按每個使用者不好直接拆，那就把一群使用者歸進乙個表好了。
blog_aa
blog_ab
blog_ac
如上所說，md5取前兩位雜湊可以達到1296張表，如果覺得不夠，那就再加一位，總數可達46656張表，還不夠?
表的數量太多，要建立這些表也是挺麻煩的，可以考慮在程式裡往資料庫insert之前，多執行一句判斷表存在與否並建立表的語句，很實用，消耗也並不很大。
主鍵：依舊要考慮的，在這個系統中，主鍵是使用者id+時間戳，單純的時間戳或自動編號也能用，但查詢時要記得帶上使用者名稱用於定位表。
四、總分結構
以上的這些結構，根據每個業務系統，能想出的估計還有很多。不過現在網際網路業務越來越複雜了，有些時候，單一的拆分法還不能實現需求，需要幾種拆分方案一起實施，多管齊下，這時候其中的邏輯會讓人繞暈。我就開發過乙個系統，僅僅是將雜湊結構和時間結構混著一用，覺得邏輯就相當複雜。
所以，除了拆表之外，按最原始的單庫單錶，再建乙個總表，是非常有利的架構。在這個架構中，每次往資料庫會寫入兩倍資料，讀取主要依賴拆表提公升效能，總表用於實現拆表後難以實現的功能並且用於每天的定時備份;另外總表和分表還相互是乙個完整的備份，任何乙個分表損壞或資料不正常，都可以從總表中讀到正確的資料並恢復，反之亦然。
在總分結構中，讓人感到質疑的是總表的效能和可維護性。我的方案是總表可採用相對能保證穩定的一些服務軟體和架構，例如oracle，或lvs+ pgpool+postgresql，重點保證資料穩定;相對的，分表就用輕量級的mysql，重點在於速度。能夠對總分表各採用不同的軟體和方案，也是總分結構的一大特點。
Mysql 分表策略
資料量大了需要考慮使用分表來減輕單錶壓力，提公升查詢效能。當然也有其他舉措，比如讀寫分離 cluster等，此文重點講分表的做法。分表有幾種做法？1.分表的原理 把常用字段如id或name取hash值，根據hash值放在不同的表中。當然也有求餘的方法，這個可以多種方法來實現。這個方法使用於論壇，發貼...
mysql 分表策略
mysql單錶資料量巨大時，查詢效能會很差，經常遇到的是儲存日誌相關的資料會每天產生大量的資料。這裡提供單錶拆分成多表儲存的三個思路 預先建立好n張表，記錄按id取模儲存到相應的表中。優點 簡單粗暴 缺點 受id模式，預先建立好錶的數量，不易擴充套件和改動。按id查詢方便，但按時間查詢就比較麻煩。資...
mysql分表策略 01
第四個問題 一張表中有都有50億條資料了，這個時候該咋辦？超過1000w一張表就要做分表了 建表 就是比如user 01，user 02 假設建立了n張同樣的表 如何做crud？在redis中儲存乙個id，每次插入一條資料，就自增 每次插入資料之間，先取出id，然後 id n 0,1,n 1 根據取...