億級大表分庫分表實戰總結（萬字干貨，實戰復盤）

以下文章來源于阿丸筆記?，作者阿丸筆記

阿丸筆記

---

分庫分表的文章網上非常多，但是大多內容比較零散，以講解知識點為主，沒有完整地說明一個大表的切分、新架構設計、上線的完整過程。

因此，我結合去年做的一個大型分庫分表項目，來復盤一下完整的分庫分表從架構設計 到 發布上線的實戰總結。

1.前言

為什么需要做分庫分表。這個相信大家多少都有所了解。

海量數據的存儲和訪問成為了MySQL數據庫的瓶頸問題，日益增長的業務數據，無疑對MySQL數據庫造成了相當大的負載，同時對于系統的穩定性和擴展性提出很高的要求。

而且單臺服務器的資源（CPU、磁盤、內存等）總是有限的，最終數據庫所能承載的數據量、數據處理能力都將遭遇瓶頸。

目前來說一般有兩種方案。

1）一種是更換存儲，不使用MySQL，比如可以使用HBase、polarDB、TiDB等分布式存儲。

2）如果出于各種原因考慮，還是想繼續使用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.6 最佳實踐

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層面。

只有新表結構和存儲架構能完全適應查詢改造，才能認為前面的設計暫時沒有問題。

當然，這里還有個前提條件，就是相關查詢已經全部收攏，沒有遺漏。

寫查詢的改造

除了相關字段的更改以外，更重要的是，需要改造為舊表、新表的雙寫模式。

這里可能涉及到具體業務寫入邏輯?，本項目尤為復雜，需要改造過程中與業務方充分溝通?，保證寫入邏輯正確。

可以在雙寫上各加一個配置開關，方便切換。如果雙寫中發現新庫寫入有問題，可以快速關閉。

同時，雙寫過程中不關閉 舊庫到新庫 的數據同步。

為什么呢？主要還是由于我們項目的特殊性。由于我們涉及到幾十個服務，為了降低風險，必須分批上線。因此，存在比較麻煩的中間態，一部分服務是老邏輯，一部分服務是新邏輯，必須保證中間態的數據正確性，具體見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），根本不再需要分庫分表呢？

繼續跟進新技術的發展，我相信會找到答案。

- END -

總結

以上是生活随笔為你收集整理的亿级大表分库分表实战总结（万字干货，实战复盘）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。