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

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

1、不切分盡量不切分

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

2、數(shù)據(jù)量過大，正常運行影響業(yè)務(wù)訪問

數(shù)據(jù)庫備份，如果表格過大，備份需要大量的磁盤IO和網(wǎng)絡(luò)IO。例如，1T的數(shù)據(jù)在網(wǎng)絡(luò)傳輸占50MB時，需要20000秒，整個過程的風(fēng)險很高。

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

大表經(jīng)常訪問和更新，鎖可能會出現(xiàn)。切分數(shù)據(jù)，用空間更換時間，變相降低訪問壓力。

3、隨著業(yè)務(wù)的發(fā)展，需要垂直拆分某些字段

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

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

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

4、數(shù)據(jù)量迅速增加

隨著業(yè)務(wù)的快速發(fā)展，表中的數(shù)據(jù)量持續(xù)增加，性能接近瓶頸時，需要考慮水平分割，制作分庫分割表。此時，必須選擇合適的分割規(guī)則，預(yù)測數(shù)據(jù)容量。

5、安全性和可用性

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

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