微信搜尋【阿丸筆記】，關注Java/MySQL/中介軟體各系列原創實戰筆記，乾貨滿滿。
分庫分表的文章網上非常多，但是大多內容比較零散，以講解知識點為主，沒有完整地說明一個大表的切分、新架構設計、上線的完整過程。
因此，我結合去年做的一個大型分庫分表專案，來複盤一下完整的分庫分表從架構設計 到 釋出上線的實戰總結。
1.前言
為什麼需要做分庫分表。這個相信大家多少都有所瞭解。
海量資料的儲存和訪問成為了MySQL資料庫的瓶頸問題，日益增長的業務資料，無疑對MySQL資料庫造成了相當大的負載，同時對於系統的穩定性和擴充套件性提出很高的要求。
而且單臺伺服器的資源（CPU、磁碟、記憶體等）總是有限的，最終資料庫所能承載的資料量、資料處理能力都將遭遇瓶頸。
目前來說一般有兩種方案。
一種是更換儲存，不使用MySQL，比如可以使用HBase、polarDB、TiDB等分散式儲存。
如果出於各種原因考慮，還是想繼續使用MySQL，一般會採用第二種方式，那就是分庫分表。
文章開頭就說了，網上分庫分表文章很多，對知識點講解比較多，因此，本文將不再過多贅述分庫分表方案的正規化處理。
而是專注於梳理分庫分表從架構設計 到 釋出上線的完整過程，同時總結其中的注意事項和最佳實踐。包括：
- 業務重構
- 技術架構設計
- 改造和上線
- 穩定性保障
- 專案管理
尤其是各個階段的最佳實踐，都是血與淚凝聚的經驗教訓。
2.第一階段：業務重構（可選）
對於微服務劃分比較合理的分庫分錶行為，一般只需要關注儲存架構的變化，或者只需要在個別應用上進行業務改造即可，一般不需要著重考慮“業務重構” 這一階段，因此，這一階段屬於“可選”。
本次專案的第一大難點，在於業務重構。
而本次拆分專案涉及到的兩張大表A和B，單表將近八千萬的資料，是從單體應用時代遺留下來的，從一開始就沒有很好的領域驅動/MSA架構設計，邏輯發散非常嚴重，到現在已經涉及50+個線上服務和20+個離線業務的的直接讀寫。
因此，如何保證業務改造的徹底性、全面性是重中之重，不能出現有遺漏的情況。
另外，表A 和 表B 各自有二、三十個欄位，兩表的主鍵存在一一對應關係，因此，本次分庫分表專案中，還需要將兩個表進行重構融合，將多餘/無用的欄位剔除。
2.1 查詢統計
線上業務通過分散式鏈路追蹤系統進行查詢，按照表名作為查詢條件，然後按照服務維度進行聚合，找到所有相關服務，寫一個文件記錄相關團隊和服務。
這裡特別注意下，很多表不是隻有線上應用在使用，很多離線演算法和資料分析的業務也在使用，這裡需要一併的梳理好，做好線下跨團隊的溝通和調研工作，以免切換後影響正常的資料分析。
2.2 查詢拆分與遷移
建立一個jar包，根據2.1的統計結果，與服務owner合作將服務中的相關查詢都遷移到這個jar包中（本專案的jar包叫projected），此處為1.0.0-SNAPSHOT版本。
然後將原本服務內的xxxMapper.xxxMethod( ) 全部改成projectdb.xxxMethod( )進行呼叫。
這樣做有兩個好處：
- 方便做後續的查詢拆分分析。
- 方便後續直接將jar包中的查詢替換為改造後 中臺服務 的rpc呼叫，業務方只需升級jar包版本，即可快速從sql呼叫改為rpc查詢。
這一步花了幾個月的實際，務必梳理各個服務做全面的遷移，不能遺漏，否則可能會導致拆分分析不全面，遺漏了相關欄位。
查詢的遷移主要由於本次拆分專案涉及到的服務太多，需要收攏到一個jar包，更方便後期的改造。如果實際分庫分表專案中僅僅涉及一兩個服務的，這一步是可以不做的。
2.3 聯合查詢的拆分分析
根據2.2收攏的jar包中的查詢，結合實際情況將查詢進行分類和判斷，把一些歷史遺留的問題，和已經廢棄的欄位做一些整理。
以下舉一些思考點。
1）哪些查詢是無法拆分的？例如分頁（儘可能地改造，實在改不了只能以冗餘列的形式）
2）哪些查詢是可以業務上join拆分的？
3）哪些表/欄位是可以融合的？
4）哪些欄位需要冗餘？
5）哪些欄位可以直接廢棄了？
6）根據業務具體場景和sql整體統計，識別關鍵的分表鍵。其餘查詢走搜尋平臺。
思考後得到一個查詢改造總體思路和方案。
同時在本專案中需要將兩張表融合為一張表，廢棄冗餘欄位和無效欄位。
2.4 新表設計
這一步基於2.3對於查詢的拆分分析，得出舊錶融合、冗餘、廢棄欄位的結果，設計新表的欄位。
產出新表設計結構後，必須發給各個相關業務方進行review，並保證所有業務方都通過該表的設計。有必要的話可以進行一次線下review。
如果新表的過程中，對部分欄位進行了廢棄，必須通知所有業務方進行確認。
對於新表的設計，除了欄位的梳理，也需要根據具體查詢，重新設計、優化索引。
2.5 第一次升級
新表設計完成後，先做一次jar包內sql查詢的改造，將舊的欄位全部更新為新表的欄位。
此處為2.0.0-SNAPSHOT版本。
然後讓所有服務升級jar包版本，以此來保證這些廢棄欄位確實是不使用了，新的表結構欄位能夠完全覆蓋過去的業務場景。
特別注意的是，由於涉及服務眾多，可以將服務按照 非核心 與 核心 區分，然後分批次上線，避免出現問題導致嚴重故障或者大範圍回滾。
2.5 最佳實踐
2.6.1 儘量不改變原表的欄位名稱
在做新表融合的時候，一開始只是簡單歸併表A 和 表B的表，因此很多欄位名相同的欄位做了重新命名。
後來欄位精簡過程中，刪除了很多重複欄位，但是沒有將重新命名的欄位改回來。
導致後期上線的過程中，不可避免地需要業務方進行重構欄位名。
因此，新表設計的時候，除非必不得已，不要修改原表的欄位名稱！
2.6.2 新表的索引需要仔細斟酌
新表的索引不能簡單照搬舊錶，而是需要根據查詢拆分分析後，重新設計。
尤其是一些欄位的融合後，可能可以歸併一些索引，或者設計一些更高效能的索引。
2.6 本章小結
至此，分庫分表的第一階段告一段落。這一階段所需時間，完全取決於具體業務，如果是一個歷史包袱沉重的業務，那可能需要花費幾個月甚至半年的時間才能完成。
這一階段的完成質量非常重要，否則可能導致專案後期需要重建表結構、重新全量資料。
這裡再次說明，對於微服務劃分比較合理的服務，分庫分錶行為一般只需要關注儲存架構的變化，或者只需要在個別應用上進行業務改造即可，一般不需要著重考慮“業務重構” 這一階段。
3.第二階段：儲存架構設計（核心）
對於任何分庫分表的專案，儲存架構的設計都是最核心的部分！
3.1 整體架構
根據第一階段整理的查詢梳理結果，我們總結了這樣的查詢規律。
- 80%以上的查詢都是通過或者帶有欄位pk1、欄位pk2、欄位pk3這三個維度進行查詢的，其中pk1和pk2由於歷史原因存在一一對應的關係
- 20%的查詢千奇百怪，包括模糊查詢、其他欄位查詢等等
因此，我們設計瞭如下的整體架構，引入了資料庫中介軟體、資料同步工具、搜尋引擎（阿里雲opensearch/ES）等。
下文的論述都是圍繞這個架構來展開的。
3.1.1 mysql分表儲存
Mysql分表的維度是根據查詢拆分分析的結果確定的。
我們發現pk1\pk2\pk3可以覆蓋80%以上的主要查詢。讓這些查詢根據分表鍵直接走mysql資料庫即可。
原則上一般最多維護一個分表的全量資料，因為過多的全量資料會造成儲存的浪費、資料同步的額外開銷、更多的不穩定性、不易擴充套件等問題。
但是由於本專案pk1和pk3的查詢語句都對實時性有比較高的要求，因此，維護了pk1和pk3作為分表鍵的兩份全量資料。
而pk2和pk1由於歷史原因，存在一一對應關係，可以僅保留一份對映表即可，只儲存pk1和pk2兩個欄位。
3.1.2 搜尋平臺索引儲存
搜尋平臺索引，可以覆蓋剩餘20%的零散查詢。
這些查詢往往不是根據分表鍵進行的，或者是帶有模糊查詢的要求。
對於搜尋平臺來說，一般不儲存全量資料（尤其是一些大varchar欄位），只儲存主鍵和查詢需要的索引欄位，搜尋得到結果後，根據主鍵去mysql儲存中拿到需要的記錄。
當然，從後期實踐結果來看，這裡還是需要做一些權衡的：
1）有些非索引欄位，如果不是很大，也可以冗餘進來，類似覆蓋索引，避免多一次sql查詢；
2）如果表結構比較簡單，欄位不大，甚至可以考慮全量儲存，提高查詢效能，降低mysql資料庫的壓力。
這裡特別提示，搜尋引擎和資料庫之間同步是必然存在延遲的。所以對於根據分表id查詢的語句，儘量保證直接查詢資料庫，這樣不會帶來一致性問題的隱患。
3.1.3 資料同步
一般新表和舊錶直接可以採用 資料同步 或者 雙寫的方式進行處理，兩種方式有各自的優缺點。
一般根據具體情況選擇一種方式就行。
本次專案的具體同步關係見整體儲存架構，包括了四個部分：
1）舊錶到新表全量主表的同步
一開始為了減少程式碼入侵、方便擴充套件，採用了資料同步的方式。而且由於業務過多，擔心有未統計到的服務沒有及時改造，所以資料同步能避免這些情況導致資料丟失。
但是在上線過程中發現，當延遲存在時，很多新寫入的記錄無法讀到，對具體業務場景造成了比較嚴重的影響。（具體原因參考4.5.1的說明）
因此，為了滿足應用對於實時性的要求，我們在資料同步的基礎上，重新在3.0.0-SNAPSHOT版本中改造成了雙寫的形式。
2）新表全量主表到全量副表的同步
3）新表全量主表到對映表到同步
4）新表全量主表到搜尋引擎資料來源的同步
2）、3）、4）都是從新表全量主表到其他資料來源的資料同步，因為沒有強實時性的要求，因此，為了方便擴充套件，全部採用了資料同步的方式，沒有進行更多的多寫操作。
3.2 容量評估
在申請mysql儲存和搜尋平臺索引資源前，需要進行容量評估，包括儲存容量和效能指標。
具體線上流量評估可以通過監控系統檢視qps，儲存容量可以簡單認為是線上各個表儲存容量的和。
但是在全量同步過程中，我們發現需要的實際容量的需求會大於預估，具體可以看3.4.6的說明。
具體效能壓測過程就不再贅述。
3.3 資料校驗
從上文可以看到，在本次專案中，存在大量的業務改造，屬於異構遷移。
從過去的一些分庫分表專案來說，大多是同構/對等拆分，因此不會存在很多複雜邏輯，所以對於資料遷移的校驗往往比較忽視。
在完全對等遷移的情況下，一般確實比較少出現問題。
但是，類似這樣有比較多改造的異構遷移，校驗絕對是重中之重！！
因此，必須對資料同步的結果做校驗，保證業務邏輯改造正確、資料同步一致性正確。這一點非常非常重要。
在本次專案中，存在大量業務邏輯優化以及欄位變動，所以我們單獨做了一個校驗服務，對資料的全量、增量進行校驗。
過程中提前發現了許多資料同步、業務邏輯的不一致問題，給我們本次專案平穩上線提供了最重要的前提保障！！
3.4 最佳實踐
3.4.1 分庫分表引起的流量放大問題
在做容量評估的時候，需要關注一個重要問題。就是分錶帶來的查詢流量放大。
這個流量放大有兩方面的原因：
- 索引表的二次查詢。比如根據pk2查詢的，需要先通過pk2查詢pk1，然後根據pk1查詢返回結果。
- in的分批查詢。如果一個select...in...的查詢，資料庫中介軟體會根據分表鍵，將查詢拆分落到對應的物理分表上，相當於原本的一次查詢，放大為多次查詢。（當然，資料庫會將落在同一個分表的id作為一次批量查詢，而這是不穩定的合併）
因此，我們需要注意：
- 業務層面儘量限制in查詢數量，避免流量過於放大；
- 容量評估時，需要考慮這部分放大因素，做適當冗餘，另外，後續會提到業務改造上線分批進行，保證可以及時擴容；
- 分64、128還是256張表有個合理預估，拆得越多，理論上會放大越多，因此不要無謂地分過多的表，根據業務規模做適當估計；
- 對於對映表的查詢，由於存在明顯的冷熱資料，所以我們又在中間加了一層快取，減少資料庫的壓力
3.4.2 分表鍵的變更方案
本專案中，存在一種業務情況會變更欄位pk3，但是pk3作為分表鍵，在資料庫中介軟體中是不能修改的，因此，只能在中臺中修改對pk3的更新邏輯，採用先刪除、後新增的方式。
這裡需要注意，刪除和新增操作的事務原子性。當然，簡單處理也可以通過日誌的方式，進行告警和校準。
3.4.3 資料同步一致性問題
我們都知道，資料同步中一個關鍵點就是（訊息）資料的順序性，如果不能保證接受的資料和產生的資料的順序嚴格一致，就有可能因為（訊息）資料亂序帶來資料覆蓋，最終帶來不一致問題。
我們自研的資料同步工具底層使用的訊息佇列是kakfa，，kafka對於訊息的儲存，只能做到區域性有序性（具體來說是每一個partition的有序）。我們可以把同一主鍵的訊息路由至同一分割槽，這樣一致性一般可以保證。但是，如果存在一對多的關係，就無法保證每一行變更有序，見如下例子。
那麼需要通過反查資料來源獲取最新資料保證一致性。
但是，反查也不是“銀彈“，需要考慮兩個問題。
1）如果訊息變更來源於讀寫例項，而反查 資料庫是查只讀例項，那就會存在讀寫例項延遲導致的資料不一致問題。因此，需要保證 訊息變更來源 和 反查資料庫 的例項是同一個。
2）反查對資料庫會帶來額外效能開銷，需要仔細評估全量時候的影響。
3.4.4 資料實時性問題
延遲主要需要注意幾方面的問題，並根據業務實際情況做評估和衡量。
1）資料同步平臺的秒級延遲
2）如果訊息訂閱和反查資料庫都是落在只讀例項上，那麼除了上述資料同步平臺的秒級延遲，還會有資料庫主從同步的延遲
3）寬表到搜尋平臺的秒級延遲
只有能夠滿足業務場景的方案，才是合適的方案。
3.4.5 分表後儲存容量優化
由於資料同步過程中，對於單表而言，不是嚴格按照遞增插入的，因此會產生很多”儲存空洞“，使得同步完後的儲存總量遠大於預估的容量。
因此，在新庫申請的時候，儲存容量多申請50%。
具體原因可以參考我的這篇文章 為什麼MySQL分庫分表後總儲存大小變大了？
3.5 本章小結
至此，分庫分表的第二階段告一段落。
這一階段踩了非常多的坑。
一方面是設計高可用、易擴充套件的儲存架構。在專案進展過程中，也做了多次的修改與討論，包括mysql資料冗餘數量、搜尋平臺的索引設計、流量放大、分表鍵修改等問題。
另一方面是“資料同步”本身是一個非常複雜的操作，正如本章最佳實踐中提及的實時性、一致性、一對多等問題，需要引起高度重視。
因此，更加依賴於資料校驗對最終業務邏輯正確、資料同步正確的檢驗！
在完成這一階段後，可以正式進入業務切換的階段。需要注意的是，資料校驗仍然會在下一階段發揮關鍵性作用。
4.第三階段：改造和上線（慎重）
前兩個階段完成後，開始業務切換流程，主要步驟如下：
1）中臺服務採用單讀 雙寫 的模式
2）舊錶往新表開著資料同步
3） 所有服務升級依賴的projectDB版本，上線RPC，如果出現問題，降版本即可回滾（上線成功後，單讀新庫，雙寫新舊庫）
4）檢查監控確保沒有 中臺服務 以外的其他服務訪問舊庫舊錶
5）停止資料同步
6）刪除舊錶
4.1 查詢改造
如何驗證我們前兩個階段設計是否合理？能否完全覆蓋查詢的修改 是一個前提條件。
當新表設計完畢後，就可以以新表為標準，修改老的查詢。
以本專案為例，需要將舊的sql在 新的中臺服務中 進行改造。
1）讀查詢的改造
可能查詢會涉及以下幾個方面：
a）根據查詢條件，需要將pk1和pk2的inner join改為對應分表鍵的新表表名
b）部分sql的廢棄欄位處理
c）非分表鍵查詢改為走搜尋平臺的查詢，注意保證語義一致
d）注意寫單測避免低階錯誤，主要是DAO層面。
只有新表結構和儲存架構能完全適應查詢改造，才能認為前面的設計暫時沒有問題。
當然，這裡還有個前提條件，就是相關查詢已經全部收攏，沒有遺漏。
2) 寫查詢的改造
除了相關欄位的更改以外，更重要的是，需要改造為舊錶、新表的雙寫模式。
這裡可能涉及到具體業務寫入邏輯，本專案尤為複雜，需要改造過程中與業務方充分溝通，保證寫入邏輯正確。
可以在雙寫上各加一個配置開關，方便切換。如果雙寫中發現新庫寫入有問題，可以快速關閉。
同時，雙寫過程中不關閉 舊庫到新庫 的資料同步。
為什麼呢？主要還是由於我們專案的特殊性。由於我們涉及到幾十個服務，為了降低風險，必須分批上線。因此，存在比較麻煩的中間態，一部分服務是老邏輯，一部分服務是新邏輯，必須保證中間態的資料正確性，具體見4.5.1的分析。
4.2 服務化改造
為什麼需要新建一個 服務來 承載改造後的查詢呢？
一方面是為了改造能夠方便的升級與回滾切換，另一方面是為了將查詢收攏，作為一箇中臺化的服務來提供相應的查詢能力。
將改造後的新的查詢放在服務中，然後jar包中的原本查詢，全部替換成這個服務的client呼叫。
同時，升級jar包版本到3.0.0-SNAPSHOT。
4.3 服務分批上線
為了降低風險，需要安排從非核心服務到核心服務的分批上線。
注意，分批上線過程中，由於寫服務往往是核心服務，所以安排在後面。可能出現非核心的讀服務上線了，這時候會有讀新表、寫舊錶的中間狀態。
1） 所有相關服務使用 重構分支 升級projectdb版本到3.0.0-SNAPSHOT並部署內網環境；
2） 業務服務依賴於 中臺服務，需要訂閱服務
3） 開重構分支（不要與正常迭代分支合併），部署內網，內網預計測試兩週以上
使用一個新的 重構分支 是為了在內網測試兩週的時候，不影響業務正常迭代。每週更新的業務分支可以merge到重構分支上部署內網，然後外網使用業務分支merge到master上部署。
當然，如果從線上線下程式碼分支一致的角度，也可以重構分支和業務分支一起測試上線，對開發和測試的壓力會較大。
4）分批上線過程中，如果碰到依賴衝突的問題，需要及時解決並及時更新到該文件中
5）服務上線前，必須要求業務開發或者測試，明確評估具體api和風險點，做好迴歸。
這裡再次提醒，上線完成後，請不要漏掉離線的資料分析業務！請不要漏掉離線的資料分析業務！請不要漏掉離線的資料分析業務！
4.4 舊錶下線流程
1）檢查監控確保沒有中臺服務以外的其他服務訪問舊庫舊錶
2）檢查資料庫上的sql審計，確保沒有其他服務仍然讀取舊錶資料
3）停止資料同步
4）刪除舊錶
4.5 最佳實踐
4.5.1 寫完立即讀可能讀不到
在分批上線過程中，遇到了寫完立即讀可能讀不到的情況。由於業務眾多，我們採用了分批上線的方式降低風險，存在一部分應用已經升級，一部分應用尚未升級的情況。未升級的服務仍然往舊錶寫資料，而升級後的應用會從新表讀資料，當延遲存在時，很多新寫入的記錄無法讀到，對具體業務場景造成了比較嚴重的影響。
延遲的原因主要有兩個：
1）寫服務還沒有升級，還沒有開始雙寫，還是寫舊錶，這時候會有讀新表、寫舊錶的中間狀態，新舊錶存在同步延遲。
2）為了避免主庫壓力，新表資料是從舊錶獲取變更、然後反查舊錶只讀例項的資料進行同步的，主從庫本身存在一定延遲。
解決方案一般有兩種：
1）資料同步改為雙寫邏輯。
2）在讀介面做補償，如果新表查不到，到舊錶再查一次。
4.5.2 資料庫中介軟體唯一ID替換自增主鍵（劃重點，敲黑板）
由於分表後，繼續使用單表的自增主鍵，會導致全域性主鍵衝突。因此，需要使用分散式唯一ID來代替自增主鍵。各種演算法網上比較多，本專案採用的是資料庫自增sequence生成方式。
資料庫自增sequence的分散式ID生成器，是一個依賴Mysql的存在， 它的基本原理是在Mysql中存入一個數值， 每有一臺機器去獲取ID的時候，都會在當前ID上累加一定的數量比如說2000， 然後把當前的值加上2000返回給伺服器。這樣每一臺機器都可以繼續重複此操作獲得唯一id區間。
但是僅僅有全域性唯一ID就大功告成了嗎？顯然不是，因為這裡還會存在新舊錶的id衝突問題。
因為服務比較多，為了降低風險需要分批上線。因此，存在一部分服務還是單寫舊錶的邏輯，一部分服務是雙寫的邏輯。
這樣的狀態中，舊錶的id策略使用的是auto_increment。如果只有單向資料來往的話（舊錶到新表），只需要給舊錶的id預留一個區間段，sequence從一個較大的起始值開始就能避免衝突。
但該專案中，還有新表資料和舊錶資料的雙寫，如果採用上述方案，較大的id寫入到舊錶，舊錶的auto_increment將會被重置到該值，這樣單鞋舊錶的服務產生的遞增id的記錄必然會出現衝突。
所以這裡交換了雙方的區間段，舊庫從較大的auto_increment起始值開始，新表選擇的id（也就是sequence的範圍）從大於舊錶的最大記錄的id開始遞增，小於舊錶auto_increment即將設定的起始值，很好的避免了id衝突問題。
1）切換前：
sequence的起始id設定為當前舊錶的自增id大小，然後舊錶的自增id需要改大，預留一段區間，給舊錶的自增id繼續使用，防止未升級業務寫入舊錶的資料同步到新庫後產生id衝突；
2）切換後
無需任何改造，斷開資料同步即可
3）優點
只用一份程式碼；
切換可以使用開關進行，不用升級改造；
如果萬一中途舊錶的autoincrement被異常資料變大了，也不會造成什麼問題。
4）缺點
如果舊錶寫失敗了，新表寫成功了，需要日誌輔助處理
4.6 本章小結
完成舊錶下線後，整個分庫分表的改造就完成了。
在這個過程中，需要始終保持對線上業務的敬畏，仔細思考每個可能發生的問題，想好快速回滾方案（在三個階段提到了projectdb的jar包版本迭代，從1.0.0-SNAPSHOT到3.0.0-SNAPSHOT，包含了每個階段不同的變更，在不同階段的分批上線的過程中，通過jar包版本的方式進行回滾，發揮了巨大作用），避免造成重大故障。
5.穩定性保障
這一章主要再次強調穩定性的保障手段。作為本次專案的重要目標之一，穩定性其實貫穿在整個專案週期內，基本上在上文各個環節都已經都有提到，每一個環節都要引起足夠的重視，仔細設計和評估方案，做到心中有數，而不是靠天吃飯：
1）新表設計必須跟業務方充分溝通、保證review。
2）對於“資料同步”，必須有資料校驗保障資料正確性，可能導致資料不正確的原因上文已經提到來很多，包括實時性、一致性的問題。保證資料正確是上線的大前提。
3）每一階段的變動，都必須做好快速回滾都預案。
4）上線過程，都以分批上線的形式，從非核心業務開始做試點，避免故障擴大。
5）監控告警要配置全面，出現問題及時收到告警，快速響應。不要忽略，很重要，有幾次出現選過資料的小問題，都是通過告警及時發現和解決的
6）單測，業務功能測試等要充分
6.專案管理之跨團隊協作
關於“跨團隊協作”，本文專門拎出來作為一章。
因為在這樣一個跨團隊的大型專案改造過程中，科學的團隊協作是保障整體專案按時、高質量完成的不可缺少的因素。
下面，分享幾點心得與體會。
6.1 一切文件先行
團隊協作最忌“空口無憑”。
無論是團隊分工、進度安排或是任何需要多人協作的事情，都需要有一個文件記錄，用於追蹤進度，把控流程。
6.2 業務溝通與確認
所有的表結構改造，必須跟相關業務方溝通，對於可能存在的歷史邏輯，進行全面梳理；
所有討論確定後的欄位改造，必須由每個服務的Owner進行確認。
6.3 責任到位
對於多團隊多人次的合作專案，每個團隊都應該明確一個對接人，由專案總負責人與團隊唯一對接人溝通，明確團隊完整進度和完成質量。
7.展望
其實，從全文的篇幅就能夠看出，本次的分庫分表專案由於複雜的業務邏輯改造，費大量的時間和精力，並且非常容易在改造過程中，引起不穩定的線上問題。
本文覆盤了整個分庫分表從拆分、設計、上線的整體過程，希望能對大家有所幫助。
看到這裡，我們會想問一句。所以，有沒有更好的方式呢？
也許，未來還是需要去結合業界新的資料庫中介軟體技術，能夠快速實現分庫分表。
也許，未來還可以引入新的資料儲存技術與方案（polardb、tidb、hbase），根本不再需要分庫分表呢？
繼續跟進新技術的發展，我相信會找到答案。
都看到最後了，原創不易，點個關注，點個贊吧～
文章持續更新，可以微信搜尋「阿丸筆記 」第一時間閱讀，回覆【筆記】獲取Canal、MySQL、HBase、JAVA實戰筆記，回覆【資料】獲取一線大廠面試資料。
知識碎片重新梳理，構建Java知識圖譜：github.com/saigu/JavaK…（歷史文章查閱非常方便）