有幸在兩家不同的公司不同程度的參與了涉及分表的項目课蔬，其背景烁峭、分表方式容客、結果均有不同秕铛，根據(jù)自己的實際感受進行了簡單的總結歸納约郁，形成此文，如有不正之處但两，歡迎各位看客指正

先說幾點自己的總結

1.為什么要分表? 及分表時機

我們都知道鬓梅，當表數(shù)據(jù)量達到一定程度后，就會有慢查出現(xiàn)谨湘。根據(jù)自己對項目的感受和觀察來看绽快，當一個表的字段不算特別多，且索引合理紧阔，大部分sql合理(少回表坊罢、盡可能不聯(lián)表或少聯(lián)表等等)的情況下，一個表的數(shù)據(jù)量可能到2000W到3000W左右就可能需要考慮分表了擅耽，到了5000W上下活孩，分表可能就已經(jīng)到了迫不及待的地步了。不過具體這個區(qū)間乖仇，也是根據(jù)自己的感受估計的憾儒，實際上參與的兩次分表均達到了5000W以上的數(shù)據(jù)量询兴，甚至第一次進行分表時數(shù)據(jù)量已經(jīng)達到三四億(除了用id查，其他的條件查詢似乎都查不動的地步)

2.分表的方式起趾？

一般情況下诗舰，有根據(jù)業(yè)務參數(shù)(例如用戶id或其他業(yè)務id)哈希或者取模的方式來分表,或者根據(jù)時間來分表例如年训裆、月眶根、周，恰好自己這兩次分表一次是按用戶id取模分表的边琉，另一次是按月分表的汛闸。具體如何選擇，感覺并無絕對的對錯艺骂，按自己總結來看主要需要考慮以下幾點:

• 分表后數(shù)據(jù)能較為均勻的分散到分表中
• 便于兼容查詢
• 從業(yè)務的角度來思考清晰合理诸老，便于以后業(yè)務擴展
• 盡量減少需要跨表merge
• 如果能通過分表來把數(shù)據(jù)的冷熱區(qū)分開就更好了
• 數(shù)據(jù)維護成本

其實兩次分表的操作在分表方式的選擇上，都是經(jīng)過一定考慮的钳恕，但后來也確實發(fā)現(xiàn)遇到了一些問題别伏，后文詳細贅述

3.關于分表后上線，及數(shù)據(jù)遷移的問題

感覺自己兩次分表經(jīng)歷在這塊都算是做的比較好的忧额，幾乎都做到了不停服或盡量少停服上線(第一次停了約1小時厘肮，第二次用戶完全無感，主要是追數(shù)據(jù)的方式不同導致的睦番，后文贅述具體情況)类茂，就是在數(shù)據(jù)字典中增加了業(yè)務開關(配置中心直接修改，不需要發(fā)版)托嚣，主要是讀開關和寫開關巩检，實話講，第一次這個設計時是有人指導的示启，第二次感覺這個方式不錯兢哭，就直接沿用保留了相關開關設計，整體的上線流程如下：
1.先寫好查分表的程序夫嗓，是一個單獨的邏輯策略類迟螺，原來查大表的是另一個策略類，策略工廠中依據(jù)讀開關和寫開關來控制走哪套策略舍咖。
2.上線時默認雙寫矩父，讀老的大表，相當于查詢完全沒改排霉，只是數(shù)據(jù)寫入的時候多寫了一份
3.等待分表的數(shù)據(jù)和老表完全一致后窍株，切換讀開關，改成讀新的分表，這樣一旦有問題還能隨時切回老表夹姥，方便快速回滾
4.穩(wěn)定一段時間后(看具體情況杉武，可以一周，也可以一個月)辙售，若老的大表確實沒有維護需求了轻抱，可將寫開關改為只寫新的分表，并在下次版本發(fā)布時旦部，將讀開關和寫開關的邏輯下掉祈搜。

4.關于id發(fā)號器

最好是有單獨的id發(fā)號器，或者簡單點就用一個自增長的只有一個主鍵的數(shù)據(jù)庫表來做id發(fā)號器(實際兩次分表都是這么玩的)士八，如果是雪花算法或者其他的方式容燕，感覺要么id不是單調(diào)的，要么過于復雜了(個人感覺)

5.關于無法通過分表字段作為條件的查詢

個人想法還是盡量在選擇分表方式的時候能夠覆蓋C端的絕大多數(shù)查詢婚度，運營后臺或者其他偏B端的服務蘸秘，可以通過構建ES寬表等方式來查詢，實在無法覆蓋的蝗茁，可以考慮根據(jù)不同的業(yè)務參數(shù)分多套表醋虏。
實在不行的，再去考慮異構索引表哮翘，不是不能解決問題颈嚼，而是一旦異構索引表查出需要跨多張表去merge數(shù)據(jù)時，性能極差饭寺。這塊感覺也回到第二點分表方案的設計時需要考慮盡量減少跨表merge的問題了

具體回顧一下自己的兩次分表實踐

一.根據(jù)業(yè)務id(uid)取模分表

1.1經(jīng)歷概述

1.2后續(xù)自己的總結與思考

1.關于課次表的合理性的一些思考：
1.1 用戶課次表的冗余比較方便的操作用戶調(diào)課/換課/退課等文虏，但確實會導致用戶的課次數(shù)據(jù)一直增加侣诺，表會膨脹，且該表的數(shù)據(jù)可以由多個小表組合得出氧秘，故當時的分析后續(xù)是取消了該表的維護年鸳，直接從業(yè)務和邏輯上改成了多個小表拼接出大表結果；
1.2 但用戶課次數(shù)據(jù)丸相，尤其是上過的課阻星，是否應該記錄下來，自己始終存在疑惑已添。

2.如果保留用戶上課的數(shù)據(jù)妥箕，是否有其他的分表方式？
2.1大學里面學校上課時更舞，也存在每個人選的課不一樣畦幢，一個老師上課同時面對多個不同的班級(子班)的情況，但一個比較大的區(qū)別在于缆蝉，大學的課都是一個學期一個學期宇葱。如果按學季分表是否能更有效的支持后續(xù)的業(yè)務？未進行驗證刊头，且單個學季的數(shù)據(jù)量會不會也很大黍瞧，此點存疑。
2.2當時的課程類型分為小原杂、初印颤、高，及特定的課程類型(講座/免費課)等穿肄，如果按具體類型分表是否能更有效的支持后續(xù)的業(yè)務年局？未進行驗證，此點存疑咸产。
2.3針對不同的業(yè)務入?yún)⑹阜瘢床煌姆绞椒直恚∠悩嬎饕砟砸纾缋蠋焷聿橹苯影磘eacher_id分表僵朗，學生來查直接按uid分表？未進行驗證屑彻，此點存疑验庙。

二.按月分表

2.1經(jīng)歷概述