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

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

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

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

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

表的存儲(chǔ)大小 256TB

那有人會(huì)說(shuō)，只要我的數(shù)據(jù)大小不超過(guò)上限，數(shù)據(jù)行數(shù)也不超過(guò)上限，是不是就沒(méi)有問(wèn)題了？其實(shí)不盡然。

在實(shí)際項(xiàng)目中，一般沒(méi)有哪個(gè)項(xiàng)目真的觸發(fā)到 MySQL 數(shù)據(jù)的上限了，因?yàn)楫?dāng)數(shù)據(jù)量變大了之后，查詢(xún)速度會(huì)慢的嚇人，而一般這個(gè)時(shí)候，你的數(shù)據(jù)量離 MySQL 的理論上限還遠(yuǎn)著呢！

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

那么接下來(lái)就和大家簡(jiǎn)單聊一聊數(shù)據(jù)庫(kù)分庫(kù)分表的問(wèn)題。

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

降低單臺(tái)數(shù)據(jù)庫(kù)實(shí)例的負(fù)載

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

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

水平切分

垂直切分

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

先來(lái)一張簡(jiǎn)單的示意圖，大家感受一下什么是水平切分：

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

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

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

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

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

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

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

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

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

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

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

先來(lái)一張簡(jiǎn)單的示意圖，大家感受一下垂直切分：

所謂的垂直切分就是拿著我的屠龍刀，對(duì)準(zhǔn)了黑色的線(xiàn)條砍?？惩曛?，將不同的表放到不同的數(shù)據(jù)庫(kù)實(shí)例中去，變成下面這個(gè)樣子：

這個(gè)時(shí)候我們發(fā)現(xiàn)如下幾個(gè)特點(diǎn)：

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

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

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

老實(shí)說(shuō)，在實(shí)際項(xiàng)目中，數(shù)據(jù)庫(kù)垂直切分并不是一件容易的事，因?yàn)楸碇g往往存在著復(fù)雜的跨庫(kù) JOIN 問(wèn)題，那么這個(gè)時(shí)候如何取舍，就要考驗(yàn)架構(gòu)師的水平了！

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

優(yōu)點(diǎn)

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

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

缺點(diǎn)

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

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

跨庫(kù) join 性能較差。

優(yōu)點(diǎn)

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

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

數(shù)據(jù)維護(hù)相對(duì)簡(jiǎn)單。

缺點(diǎn)

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

跨庫(kù) join 不易。

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

雖然 MySQL 中數(shù)據(jù)存儲(chǔ)的理論上限比較高，但是在實(shí)際開(kāi)發(fā)中我們不會(huì)等到數(shù)據(jù)存不下的時(shí)候才去考慮分庫(kù)分表問(wèn)題，因?yàn)樵谀侵?，你就?huì)明顯的感覺(jué)到數(shù)據(jù)庫(kù)的各項(xiàng)性能在下降，就要開(kāi)始考慮分庫(kù)分表了。

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

參考資料：

MySQL 官方文檔

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