隨著現在互聯網應用的普及，使得數據庫的負載非常高，而復雜的數據訪問與儲存問題成了不少企業組織的大難題。數據庫切分是系統中最關鍵的核心環節也是瓶頸。數據庫切分是為了保護數據庫，增加緩存。當然并非所有的表都需要切分，這主要還是看具體數據的成長速度。在實際的數據處理中，數據庫切分的原則包括：能夠不切分就盡量不切分，在數據量過大的情況下，正常運行已經影響了業務訪問就需要切分，企業的業務量不斷擴展，需要垂直拆分某些字段等等，下面我們就來詳細介紹一下它的切分原則。

分割后，在一定程度上提高業務復雜性，數據庫除了載入數據的存儲和查詢外，協助業務更好地實現需求也是其重要工作之一。數據庫切分的五大原則：

1、不切分盡量不切分

不要輕易使用分庫表這個“大把戲”，避免“過度設計”和“過早優化”。在分庫表之前，不要為了得分而得分。首先，升級硬件、升級網絡、讀寫分離、索引優化等，盡最大努力。數據量達到單表瓶頸時，請考慮分庫表。

2、數據量過大，正常運行影響業務訪問

數據庫備份，如果表格過大，備份需要大量的磁盤IO和網絡IO。例如，1T的數據在網絡傳輸占50MB時，需要20000秒，整個過程的風險很高。

修改大型DDL時，MySQL鎖定全表，此時間長，此時業務無法訪問該表，影響大。如果使用pt-online-schema-change，在使用過程中會制作觸發器和影表，也需要很長時間。在這個操作過程中，被認為是風險時間。分割數據表，減少總量，有助于降低這一風險。

大表經常訪問和更新，鎖可能會出現。切分數據，用空間更換時間，變相降低訪問壓力。

3、隨著業務的發展，需要垂直拆分某些字段

舉個例子，開始設計的用戶表如圖18-1：

在項目初期階段，該設計符合簡單的業務需求，便于快速反復開發。業務迅速發展時，用戶數從10w急劇增加到10億，用戶非常活躍，每次登錄都更新last_login_name字段，user表不斷變成update，壓力很大。其他字段:id、name、personal_info不變或更新較少。此時，從業務角度分割last_login_time，建立新的user_time表。

personal_info屬性更新查詢頻率低，text字段占用空間過大。此時，必須垂直分割user_ext表。

4、數據量迅速增加

隨著業務的快速發展，表中的數據量持續增加，性能接近瓶頸時，需要考慮水平分割，制作分庫分割表。此時，必須選擇合適的分割規則，預測數據容量。

5、安全性和可用性

雞蛋不要放在籃子里。在業務水平上垂直分割，分割不相關業務的數據庫，每個業務的數據量、訪問量不同，所以因為一個業務搞掛而牽連其他數據庫。利用水平切分，當數據庫出現問題時，不會影響100%的用戶，每個庫只承擔業務的一部分數據，可以提高整體的可用性。

以上我們介紹了數據庫切分的五大原則，這些簡單的知識在您的工作中也許用得上，如果您想了解更多相關信息，請您繼續關注中培偉業。