原因和目的

• 由於交易量大或者日積月累造成資料庫的資料量越來越大。會導致系統性能大幅下降，所以要對部分業務的表資料作備份和清理
• 減少資料量，來提升請求響應的速度，提升使用者體驗

資料是否需要清理的閥值判斷

通常當表的磁碟大小超過 5GB，或對於 OLTP 系統(聯機事務處理)，表的記錄超過 3000 萬，都應考慮對錶進行分割槽或者分表。
除了上述閥值之外，還可以根據資料庫效能指標情況來考慮分割槽或者分表，比如在已經充分挖掘了表設計、索引設計、查詢設計等單表效能優化手段之後，依然不能滿足業務的需要，這個時候，即使表的容量或記錄尚未達到上述閥值那也要考慮分割槽或者分表了，這個時間點的記錄數即為該表閥值。
一般來講，用記錄數標記閥值會比表的磁碟容量更容易操作一些，所以一般以達到該閥值時的記錄數作為閥值，下文也會以此來作為閥值。每個表的資料格式不同、索引設計、單位事務處理時間容忍度不同，所以這個閥值也不同。

滿負載週期判斷

也就是說，一張空表，需要多久才能達到它的閥值，這個週期我們稱之為滿負載週期。
如果業務量已經穩定，資料量積累到當前閥值所需要的時間即為該表滿負載週期；如果業務量穩定上升，即資料量在遞增，根據遞增速度估算出下一個滿負載週期——也就是說，什麼時候到達閥值什麼時候進行遷移，但我們要做到提前規劃，心中有數。

遷移週期判斷

拿到該表閥值之後，需要對遷移週期進行判斷，即多久對該表遷移一次？
可以一天遷移到歷史表一次，即遷移週期就是一天。這樣操作很簡單，完全可以做成定時任務，所以很多系統這麼幹，只是有些頻繁。

也可以用三分法，即滿負載週期後，找出後 1/3 週期的資料進行遷移，那麼遷移週期就是 1/3 個滿負載週期。這樣雖然比較有計劃性，但是操作稍微複雜(特別是業務量不穩定的時候)，而且每次遷移可能需要開發、運維共同計劃、參與。

資料的流向歷史

當前表 -> 歷史表 -> 備份表

如上圖所示，綠色代表當前表，表示雖然存在高頻率的寫入操作，但是表的查詢效能是非常高的；黃色代表歷史表，表示寫入頻率已經很小，但是還是有一些查詢需求，查詢效能很高；灰色代表備份表，表示資料到了這張表中已經不再提供寫入操作，視情況會提供查詢操作，查詢效能一般。

不同型別資料的分割槽方案

• 聯機交易(實時類交易，寫頻繁)只提供當日交易查詢，建立AB表進行日切，每日對切換下來不提供服務的那張表進行遷移；遷移後的聯機交易進入聯機歷史表，之後對原表(A 或 B 表)執行 truncate 操作；歷史表以交易建立時間(或更新時間，或完成時間)進行 range 分割槽操作(比如按月分割槽，具體看業務量遞增情況)
• 清分交易(非實時類交易，讀頻繁)供當日之外的聯機交易查詢、平臺查詢以及清分等資料操作；可以按月對清分交易進行分表操作，但是這樣做的話前端應用需要對清分查詢進行資料庫路由，並對跨月查詢結果進行整合過濾；所以清分表最好還是建立當前表歷史表機制，根據遷移週期進行定期遷移
• 日誌類資料同非實時類交易
• 使用者認證資訊(訪問度不高，讀大於寫)，根據業務查詢需要可以考慮按照時間進行 range 分割槽(推薦 range，可擴充套件性較高，一般來講即使業務量暴增也能滿足需要)，或者按照使用者 id 進行 hash 或 range 分割槽，分割槽欄位的選取可以參考"注意的點"中列舉的事項

歷史表的清理方案

• 交易類(包括聯機、清分、分潤)的資料5年清理一次
• 日誌類的資料5年清理一次
• 使用者認證、商戶認證類資料一直保留

注意的點

• 日誌類表(操作日誌、系統日誌、結果記錄、任務記錄等)的分割槽處理：按時間進行分割槽
• 交易類表(流水、明細、對賬、差異等)的分割槽處理：按建立時間或更新時間進行分割槽
• 通知類表的分割槽處理：按時間進行分割槽
• 分割槽欄位的選取：一般是以最經常查詢的那個欄位來進行分割槽，這樣會有助於提高查詢速度。不建議使用 id 進行分割槽，除非業務系統裡固定的 id=? 查詢特別多，否則不僅是對分割槽索引的浪費，而且可能會比沒有分割槽還要慢
• 不管是 range 分割槽，還是 hash 分割槽，在做分割槽的時候都要考慮到分割槽的可擴充套件性，原則上分割槽後的 2 年內不應該再考慮重新分割槽的事情，分割槽到期後根據業務量增長情況再加 2 年的分割槽…以此類推
• 各個分割槽內的資料要較為均勻，不要太多也不要太少，而且根據分割槽欄位可以很快定位到分割槽範圍
• 具體每個分割槽內資料量多少合適？原則上是把資料的範圍縮小到一個即使做全盤掃描也不會慢的時候為最佳，視具體情況為幾十萬或上百萬不等
  
• 相關業務操作(SQL)儘量在同一個分割槽內部完成。必須跨分割槽提取的話建議並行提取以提高速度