面試總被問分庫分表怎么辦？這些知識點你要懂
引言
微服務、分布式大行其道的當下，中、高級Java工程師面試題中高并發、大數據量、分庫分表等已經成了面試的高頻詞匯，這些知識不了解面試通過率不會太高。
你可以不會用，但你不能不知道，就是這么一種現狀。技術名詞大多晦澀難懂，不要死記硬背理解最重要，當你捅破那層窗戶紙，發現其實它也就那么回事。
一、為什么要分庫分表
關系型數據庫以MySQL為例，單機的存儲能力、連接數是有限的，它自身就很容易會成為系統的瓶頸。當單表數據量在百萬以里時，我們還可以通過添加從庫、優化索引提升性能。
一旦數據量朝著千萬以上趨勢增長，再怎么優化數據庫，很多操作性能仍下降嚴重。為了減少數據庫的負擔，提升數據庫響應速度，縮短查詢時間，這時候就需要進行分庫分表。
二、如何分庫分表
分庫分表就是要將大量數據分散到多個數據庫中，使每個數據庫中數據量小響應速度快，以此來提升數據庫整體性能。
核心理念就是對數據進行切分（Sharding），以及切分后如何對數據的快速定位與整合。
針對數據切分類型，大致可以分為：垂直（縱向）切分和水平（橫向）切分兩種。
1、垂直切分
垂直切分又細分為垂直分庫和垂直分表
垂直分庫
垂直分庫是基于業務分類的，和我們常聽到的微服務治理觀念很相似，每一個獨立的服務都擁有自己的數據庫，需要不同業務的數據需接口調用。
而垂直分庫也是按照業務分類進行劃分，每個業務有獨立數據庫，這個比較好理解。
垂直分表
垂直分表是基于數據表的列為依據切分的，是一種大表拆小表的模式。
例如：一個order表有很多字段，把長度較大且訪問不頻繁的字段，拆分出來創建一個單獨的擴展表work_extend進行存儲。
order表：
| id | workNo | price | describe | … |
|---|---|---|---|---|
| int（12) | int（2) | int（15) | varchar（2000) |
order核心表：
| id | workNo | price | … |
|---|---|---|---|
| int（12) | int（2) | int（15) |
work_extend表：
| id | workNo | describe | … |
|---|---|---|---|
| int（12) | int（2) | varchar（2000) |
數據庫是以行為單位將數據加載到內存中，這樣拆分以后核心表大多是訪問頻率較高的字段，而且字段
長度也都較短，可以加載更多數據到內存中，增加查詢的命中率，減少磁盤IO，以此來提升數據庫性能。
優點：
- 業務間解耦，不同業務的數據進行獨立的維護、監控、擴展
- 在高并發場景下，一定程度上緩解了數據庫的壓力
缺點：
- 提升了開發的復雜度，由于業務的隔離性，很多表無法直接訪問，必須通過接口方式聚合數據，
- 分布式事務管理難度增加
- 數據庫還是存在單表數據量過大的問題，并未根本上解決，需要配合水平切分
2、水平切分
前邊說了垂直切分還是會存在單表數據量過大的問題，當我們的應用已經無法在細粒度的垂直切分時，
依舊存在單庫讀寫、存儲性能瓶頸，這時就要配合水平切分一起了。
水平切分將一張大數據量的表，切分成多個表結構相同，而每個表只占原表一部分數據，然后按不同的條件分散到多個數據庫中。
假如一張order表有2000萬數據，水平切分后出來四個表，order_1、order_2、order_3、order_4，每張表數據500萬，以此類推。
order_1表：
| id | workNo | price | describe | … |
|---|---|---|---|---|
| int（12) | int（2) | int（15) | varchar（200 |
order_2表：
| id | workNo | price | describe | … |
|---|---|---|---|---|
| int（12) | int（2) | int（15) | varchar（200 |
order_3表：
| id | workNo | price | describe | … |
|---|---|---|---|---|
| int（12) | int（2) | int（15) | varchar（200 |
order_4表：
| id | workNo | price | describe | … |
|---|---|---|---|---|
| int（12) | int（2) | int（15) | varchar（200 |
水平切分又分有庫內分表和分庫分表
庫內分表
庫內分表雖然將表拆分，但子表都還是在同一個數據庫實例中，只是解決了單一表數據量過大的問題，并沒有將拆分后的表分布到不同機器的庫上，還在競爭同一個物理機的CPU、內存、網絡IO。
分庫分表
分庫分表則是將切分出來的子表，分散到不同的數據庫中，從而使得單個表的數據量變小，達到分布式的效果。
優點：
- 解決高并發時單庫數據量過大的問題，提升系統穩定性和負載能力
- 業務系統改造的工作量不是很大
缺點：
- 跨分片的事務一致性難以保證
- 跨庫的join關聯查詢性能較差
- 擴容的難度和維護量較大，（拆分成幾千張子表想想都恐怖）
三、數據該往哪個庫的表存？
分庫分表以后會出現一個問題，一張表會出現在多個數據庫里，到底該往哪個庫的表里存呢？
1、根據取值范圍
按照時間區間或ID區間來切分，舉個栗子：假如我們切分的是用戶表，可以定義每個庫的User表里只存10000條數據，第一個庫userId從1 ~ 9999，第二個庫10000 ~ 20000，第三個庫20001~ 30000……以此類推。
優點：
- 單表數據量是可控的
- 水平擴展簡單只需增加節點即可，無需對其他分片的數據進行遷移
- 能快速定位要查詢的數據在哪個庫
缺點：
- 由于連續分片可能存在數據熱點，如果按時間字段分片，有些分片存儲最近時間段內的數據，可能會被頻繁的讀寫，而有些分片存儲的歷史數據，則很少被查詢
2、hash取模
hash取模mod（對hash結果取余數 (hash() mod N)）的切分方式比較常見，還拿User表舉例，對數據庫從0到N-1進行編號，對User表中userId字段進行取模，得到余數i，i=0存第一個庫，i=1存第二個庫，i=2存第三個庫….以此類推。
這樣同一個用戶的數據都會存在同一個庫里，用userId作為條件查詢就很好定位了
優點：
- 數據分片相對比較均勻，不易出現某個庫并發訪問的問題
缺點：
- 但這種算法存在一些問題，當某一臺機器宕機，本應該落在該數據庫的請求就無法得到正確的處理，這時宕掉的實例會被踢出集群，此時算法變成hash(userId) mod N-1，用戶信息可能就不再在同一個庫中。
四、分庫分表后會有哪些坑？
1、事務一致性問題
由于表分布在不同庫中，不可避免會帶來跨庫事務問題。一般可使用"XA協議"和"兩階段提交"處理，但是這種方式性能較差，代碼開發量也比較大。
通常做法是做到最終一致性的方案，往往不苛求系統的實時一致性，只要在允許的時間段內達到最終一致性即可，可采用事務補償的方式。
2、分頁、排序的坑
日常開發中分頁、排序是必備功能，而多庫進行查詢時limit分頁、order by排序，著實讓人比較頭疼。
分頁需按照指定字段進行排序，如果排序字段恰好是分片字段時，通過分片規則就很容易定位到分片的位置；一旦排序字段非分片字段時，就需要先在不同的分片節點中將數據進行排序并返回，然后將不同分片返回的結果集進行匯總和再次排序，最終返回給用戶，過程比較復雜。
3、全局唯一主鍵問題
由于分庫分表后，表中的數據同時存在于多個數據庫，而某個分區數據庫的自增主鍵已經無法滿足全局
唯一，所以此時一個能夠生成全局唯一ID的系統是非常必要的。那么這個全局唯一ID就叫分布式ID。
可以參考我之前寫的這篇文章《一口氣說出 9種 分布式ID生成方式，面試官有點懵了》
五、分庫分表工具？
自己開發分庫分表工具的工作量是巨大的，好在業界已經有了很多比較成熟的分庫分表中間件，我們可
以將更多的時間放在業務實現上
- sharding-jdbc（當當）
- TSharding（蘑菇街）
- Atlas（奇虎360）
- Cobar（阿里巴巴）
- MyCAT（基于Cobar）
- Oceanus（58同城） Vitess（谷歌）
