摘要：這里的某種規(guī)則都包含哪些規(guī)則呢這就涉及到數(shù)據(jù)庫的分片規(guī)則問題了，這個松哥在后面的文章中也會和大家一一展開詳述。

千萬量級的數(shù)據(jù)，用 MySQL 要怎么存？

初學(xué)者在看到這個問題的時候，可能首先想到的是 MySQL 一張表到底能存放多少條數(shù)據(jù)？

根據(jù) MySQL 官方文檔的介紹，MySQL 理論上限是 (2³²)² 條數(shù)據(jù)，然而實際操作中，往往還受限于下面兩條因素：

myisam_data_pointer_size，MySQL 的 myisam_data_pointer_size 一般默認(rèn)是 6，即 48 位，那么對應(yīng)的行數(shù)就是 2⁴⁸-1。

表的存儲大小 256TB

那有人會說，只要我的數(shù)據(jù)大小不超過上限，數(shù)據(jù)行數(shù)也不超過上限，是不是就沒有問題了？其實不盡然。

在實際項目中，一般沒有哪個項目真的觸發(fā)到 MySQL 數(shù)據(jù)的上限了，因為當(dāng)數(shù)據(jù)量變大了之后，查詢速度會慢的嚇人，而一般這個時候，你的數(shù)據(jù)量離 MySQL 的理論上限還遠(yuǎn)著呢！

傳統(tǒng)的企業(yè)應(yīng)用一般數(shù)據(jù)量都不大，數(shù)據(jù)也都比較容易處理，但是在互聯(lián)網(wǎng)項目中，上千萬、上億的數(shù)據(jù)量并不鮮見。在這種時候，還要保證數(shù)據(jù)庫的操作效率，我們就不得不考慮數(shù)據(jù)庫的分庫分表了。

那么接下來就和大家簡單聊一聊數(shù)據(jù)庫分庫分表的問題。

看這個名字就知道，就是把一個數(shù)據(jù)庫切分成 N 多個數(shù)據(jù)庫，然后存放在不同的數(shù)據(jù)庫實例上面，這樣做有兩個好處：

降低單臺數(shù)據(jù)庫實例的負(fù)載

可以方便的實現(xiàn)對數(shù)據(jù)庫的擴(kuò)容

一般來說，數(shù)據(jù)庫的切分有兩種不同的切分規(guī)則：

水平切分

垂直切分

接下來我們就對這兩種不同的切分規(guī)則分別進(jìn)行介紹。

先來一張簡單的示意圖，大家感受一下什么是水平切分：

假設(shè)我的 DB 中有 table-1、table-2 以及 table-3 三張表，水平切分就是拿著我的絕世好劍，對準(zhǔn)黑色的線條，砍一劍或者砍 N 劍！

砍完之后，將砍掉的部分放到另外一個數(shù)據(jù)庫實例中，變成下面這樣：

這樣，原本放在一個 DB 中的 table 現(xiàn)在放在兩個 DB 中了，觀察之后我們發(fā)現(xiàn)：

兩個 DB 中表的個數(shù)都是完整的，就是原來 DB 中有幾張表，現(xiàn)在還是幾張。

每張表中的數(shù)據(jù)是不完整的，數(shù)據(jù)被拆分到了不同的 DB 中去了。

這就是數(shù)據(jù)庫的水平切分，也可以理解為按照數(shù)據(jù)行進(jìn)行切分，即按照表中某個字段的某種規(guī)則來將表數(shù)據(jù)分散到多個庫之中，每個表中包含一部分?jǐn)?shù)據(jù)。

這里的某種規(guī)則都包含哪些規(guī)則呢？這就涉及到數(shù)據(jù)庫的分片規(guī)則問題了，這個松哥在后面的文章中也會和大家一一展開詳述。這里先簡單說幾個常見的分片規(guī)則：

按照日期劃分：不容日期的數(shù)據(jù)存放到不同的數(shù)據(jù)庫中。

對 ID 取模：對表中的 ID 字段進(jìn)行取模運(yùn)算，根據(jù)取模結(jié)果將數(shù)據(jù)保存到不同的實例中。

使用一致性哈希算法進(jìn)行切分。

詳細(xì)的用法，將在后面的文章中和大家仔細(xì)說。

先來一張簡單的示意圖，大家感受一下垂直切分：

所謂的垂直切分就是拿著我的屠龍刀，對準(zhǔn)了黑色的線條砍?？惩曛螅瑢⒉煌谋矸诺讲煌臄?shù)據(jù)庫實例中去，變成下面這個樣子：

這個時候我們發(fā)現(xiàn)如下幾個特點：

每一個數(shù)據(jù)庫實例中的表的數(shù)量都是不完整的。

每一個數(shù)據(jù)庫實例中表的數(shù)據(jù)是完整的。

這就是垂直切分。一般來說，垂直切分我們可以按照業(yè)務(wù)來劃分，不同業(yè)務(wù)的表放到不同的數(shù)據(jù)庫實例中。

老實說，在實際項目中，數(shù)據(jù)庫垂直切分并不是一件容易的事，因為表之間往往存在著復(fù)雜的跨庫 JOIN 問題，那么這個時候如何取舍，就要考驗架構(gòu)師的水平了！

通過上面的介紹，相信大家對于水平切分和垂直切分已經(jīng)有所了解，優(yōu)缺點其實也很明顯了，松哥再來和大家總結(jié)一下。

優(yōu)點

水平切分最大的優(yōu)勢在于數(shù)據(jù)庫的擴(kuò)展性好，提前選好切分規(guī)則，數(shù)據(jù)庫后期可以非常方便的進(jìn)行擴(kuò)容。

有效提高了數(shù)據(jù)庫穩(wěn)定性和系統(tǒng)的負(fù)載能力。拆分規(guī)則抽象好， join 操作基本可以數(shù)據(jù)庫做。

缺點

水平切分后，分片事務(wù)一致性不容易解決。

拆分規(guī)則不易抽象，對架構(gòu)師水平要求很高。

跨庫 join 性能較差。

優(yōu)點

一般按照業(yè)務(wù)拆分，拆分后業(yè)務(wù)清晰，可以結(jié)合微服務(wù)一起食用。

系統(tǒng)之間整合或擴(kuò)展相對要容易很多。

數(shù)據(jù)維護(hù)相對簡單。

缺點

最大的問題在于存在單庫性能瓶頸，數(shù)據(jù)表擴(kuò)展不易。

跨庫 join 不易。

事務(wù)處理復(fù)雜。

雖然 MySQL 中數(shù)據(jù)存儲的理論上限比較高，但是在實際開發(fā)中我們不會等到數(shù)據(jù)存不下的時候才去考慮分庫分表問題，因為在那之前，你就會明顯的感覺到數(shù)據(jù)庫的各項性能在下降，就要開始考慮分庫分表了。

好了，今天主要是向大家介紹一點概念性的東西，算是我們分布式數(shù)據(jù)庫中間件正式出場前的一點鋪墊。

參考資料：

MySQL 官方文檔

關(guān)注公眾號【江南一點雨】，專注于 Spring Boot+微服務(wù)以及前后端分離等全棧技術(shù)，定期視頻教程分享，關(guān)注后回復(fù) Java ，領(lǐng)取松哥為你精心準(zhǔn)備的 Java 干貨！