一，數(shù)據(jù)切分

關系型數(shù)據(jù)庫本身比較容易成為系統(tǒng)瓶頸，單機存儲容量、連接數(shù)、處理能力都有限。當單表的數(shù)據(jù)量達到1000W或100G以后，由于查詢維度較多，即使添加從庫、優(yōu)化索引，做很多操作時性能仍下降嚴重。此時就要考慮對其進行切分了，切分的目的就在于減少數(shù)據(jù)庫的負擔，縮短查詢時間。

數(shù)據(jù)庫分布式核心內(nèi)容無非就是數(shù)據(jù)切分（Sharding），以及切分后對數(shù)據(jù)的定位、整合。數(shù)據(jù)切分就是將數(shù)據(jù)分散存儲到多個數(shù)據(jù)庫中，使得單一數(shù)據(jù)庫中的數(shù)據(jù)量變小，通過擴充主機的數(shù)量緩解單一數(shù)據(jù)庫的性能問題，從而達到提升數(shù)據(jù)庫操作性能的目的。

數(shù)據(jù)切分根據(jù)其切分類型，可以分為兩種方式：垂直（縱向）切分和水平（橫向）切分

1、垂直（縱向）切分

垂直切分常見有垂直分庫和垂直分表兩種。

垂直分庫就是根據(jù)業(yè)務耦合性，將關聯(lián)度低的不同表存儲在不同的數(shù)據(jù)庫。做法與大系統(tǒng)拆分為多個小系統(tǒng)類似，按業(yè)務分類進行獨立劃分。與"微服務治理"的做法相似，每個微服務使用單獨的一個數(shù)據(jù)庫。如圖：

垂直分表是基于數(shù)據(jù)庫中的"列"進行，某個表字段較多，可以新建一張擴展表，將不經(jīng)常用或字段長度較大的字段拆分出去到擴展表中。在字段很多的情況下（例如一個大表有100多個字段），通過"大表拆小表"，更便于開發(fā)與維護，也能避免跨頁問題，MySQL底層是通過數(shù)據(jù)頁存儲的，一條記錄占用空間過大會導致跨頁，造成額外的性能開銷。另外數(shù)據(jù)庫以行為單位將數(shù)據(jù)加載到內(nèi)存中，這樣表中字段長度較短且訪問頻率較高，內(nèi)存能加載更多的數(shù)據(jù)，命中率更高，減少了磁盤IO，從而提升了數(shù)據(jù)庫性能。

垂直切分的優(yōu)點：

• 解決業(yè)務系統(tǒng)層面的耦合，業(yè)務清晰
• 與微服務的治理類似，也能對不同業(yè)務的數(shù)據(jù)進行分級管理、維護、監(jiān)控、擴展等
• 高并發(fā)場景下，垂直切分一定程度的提升IO、數(shù)據(jù)庫連接數(shù)、單機硬件資源的瓶頸

缺點：

• 部分表無法join，只能通過接口聚合方式解決，提升了開發(fā)的復雜度
• 分布式事務處理復雜
• 依然存在單表數(shù)據(jù)量過大的問題（需要水平切分）

2、水平（橫向）切分

當一個應用難以再細粒度的垂直切分，或切分后數(shù)據(jù)量行數(shù)巨大，存在單庫讀寫、存儲性能瓶頸，這時候就需要進行水平切分了。

水平切分分為庫內(nèi)分表和分庫分表，是根據(jù)表內(nèi)數(shù)據(jù)內(nèi)在的邏輯關系，將同一個表按不同的條件分散到多個數(shù)據(jù)庫或多個表中，每個表中只包含一部分數(shù)據(jù)，從而使得單個表的數(shù)據(jù)量變小，達到分布式的效果。如圖所示：

庫內(nèi)分表只解決了單一表數(shù)據(jù)量過大的問題，但沒有將表分布到不同機器的庫上，因此對于減輕MySQL數(shù)據(jù)庫的壓力來說，幫助不是很大，大家還是競爭同一個物理機的CPU、內(nèi)存、網(wǎng)絡IO，最好通過分庫分表來解決。

水平切分的優(yōu)點：

• 不存在單庫數(shù)據(jù)量過大、高并發(fā)的性能瓶頸，提升系統(tǒng)穩(wěn)定性和負載能力
• 應用端改造較小，不需要拆分業(yè)務模塊

缺點：

• 跨分片的事務一致性難以保證
• 跨庫的join關聯(lián)查詢性能較差
• 數(shù)據(jù)多次擴展難度和維護量極大

水平切分后同一張表會出現(xiàn)在多個數(shù)據(jù)庫/表中，每個庫/表的內(nèi)容不同。幾種典型的數(shù)據(jù)分片規(guī)則為：

1、根據(jù)數(shù)值范圍

按照時間區(qū)間或ID區(qū)間來切分。例如：按日期將不同月甚至是日的數(shù)據(jù)分散到不同的庫中；將userId為1~9999的記錄分到第一個庫，10000~20000的分到第二個庫，以此類推。某種意義上，某些系統(tǒng)中使用的"冷熱數(shù)據(jù)分離"，將一些使用較少的歷史數(shù)據(jù)遷移到其他庫中，業(yè)務功能上只提供熱點數(shù)據(jù)的查詢，也是類似的實踐。

這樣的優(yōu)點在于：

• 單表大小可控
• 天然便于水平擴展，后期如果想對整個分片集群擴容時，只需要添加節(jié)點即可，無需對其他分片的數(shù)據(jù)進行遷移
• 使用分片字段進行范圍查找時，連續(xù)分片可快速定位分片進行快速查詢，有效避免跨分片查詢的問題。

缺點：

• 熱點數(shù)據(jù)成為性能瓶頸。連續(xù)分片可能存在數(shù)據(jù)熱點，例如按時間字段分片，有些分片存儲最近時間段內(nèi)的數(shù)據(jù)，可能會被頻繁的讀寫，而有些分片存儲的歷史數(shù)據(jù)，則很少被查詢

2、根據(jù)數(shù)值取模

一般采用hash取模mod的切分方式，例如：將 Customer 表根據(jù) cusno 字段切分到4個庫中，余數(shù)為0的放到第一個庫，余數(shù)為1的放到第二個庫，以此類推。這樣同一個用戶的數(shù)據(jù)會分散到同一個庫中，如果查詢條件帶有cusno字段，則可明確定位到相應庫去查詢。

優(yōu)點：

• 數(shù)據(jù)分片相對比較均勻，不容易出現(xiàn)熱點和并發(fā)訪問的瓶頸

缺點：

• 后期分片集群擴容時，需要遷移舊的數(shù)據(jù)（使用一致性hash算法能較好的避免這個問題）
• 容易面臨跨分片查詢的復雜問題。比如上例中，如果頻繁用到的查詢條件中不帶cusno時，將會導致無法定位數(shù)據(jù)庫，從而需要同時向4個庫發(fā)起查詢，再在內(nèi)存中合并數(shù)據(jù)，取最小集返回給應用，分庫反而成為拖累。

二. 分庫分表帶來的問題

分庫分表能有效的環(huán)節(jié)單機和單庫帶來的性能瓶頸和壓力，突破網(wǎng)絡IO、硬件資源、連接數(shù)的瓶頸，同時也帶來了一些問題。下面將描述這些技術挑戰(zhàn)以及對應的解決思路。

1、事務一致性問題

分布式事務

當更新內(nèi)容同時分布在不同庫中，不可避免會帶來跨庫事務問題。跨分片事務也是分布式事務，沒有簡單的方案，一般可使用"XA協(xié)議"和"兩階段提交"處理。

分布式事務能最大限度保證了數(shù)據(jù)庫操作的原子性。但在提交事務時需要協(xié)調(diào)多個節(jié)點，推后了提交事務的時間點，延長了事務的執(zhí)行時間。導致事務在訪問共享資源時發(fā)生沖突或死鎖的概率增高。隨著數(shù)據(jù)庫節(jié)點的增多，這種趨勢會越來越嚴重，從而成為系統(tǒng)在數(shù)據(jù)庫層面上水平擴展的枷鎖。

最終一致性

對于那些性能要求很高，但對一致性要求不高的系統(tǒng)，往往不苛求系統(tǒng)的實時一致性，只要在允許的時間段內(nèi)達到最終一致性即可，可采用事務補償?shù)姆绞健Ｅc事務在執(zhí)行中發(fā)生錯誤后立即回滾的方式不同，事務補償是一種事后檢查補救的措施，一些常見的實現(xiàn)方法有：對數(shù)據(jù)進行對賬檢查，基于日志進行對比，定期同標準數(shù)據(jù)來源進行同步等等。事務補償還要結(jié)合業(yè)務系統(tǒng)來考慮。

2、跨節(jié)點關聯(lián)查詢 join 問題

切分之前，系統(tǒng)中很多列表和詳情頁所需的數(shù)據(jù)可以通過sql join來完成。而切分之后，數(shù)據(jù)可能分布在不同的節(jié)點上，此時join帶來的問題就比較麻煩了，考慮到性能，盡量避免使用join查詢。

解決這個問題的一些方法：

1）全局表

全局表，也可看做是"數(shù)據(jù)字典表"，就是系統(tǒng)中所有模塊都可能依賴的一些表，為了避免跨庫join查詢，可以將這類表在每個數(shù)據(jù)庫中都保存一份。這些數(shù)據(jù)通常很少會進行修改，所以也不擔心一致性的問題。

2）字段冗余

一種典型的反范式設計，利用空間換時間，為了性能而避免join查詢。例如：訂單表保存userId時候，也將userName冗余保存一份，這樣查詢訂單詳情時就不需要再去查詢"買家user表"了。

但這種方法適用場景也有限，比較適用于依賴字段比較少的情況。而冗余字段的數(shù)據(jù)一致性也較難保證，就像上面訂單表的例子，買家修改了userName后，是否需要在歷史訂單中同步更新呢？這也要結(jié)合實際業(yè)務場景進行考慮。

3）數(shù)據(jù)組裝

在系統(tǒng)層面，分兩次查詢，第一次查詢的結(jié)果集中找出關聯(lián)數(shù)據(jù)id，然后根據(jù)id發(fā)起第二次請求得到關聯(lián)數(shù)據(jù)。最后將獲得到的數(shù)據(jù)進行字段拼裝。

4）ER分片

關系型數(shù)據(jù)庫中，如果可以先確定表之間的關聯(lián)關系，并將那些存在關聯(lián)關系的表記錄存放在同一個分片上，那么就能較好的避免跨分片join問題。在1:1或1:n的情況下，通常按照主表的ID主鍵切分。如下圖所示：

這樣一來，Data Node1上面的order訂單表與orderdetail訂單詳情表就可以通過orderId進行局部的關聯(lián)查詢了，Data Node2上也一樣。

3、跨節(jié)點分頁、排序、函數(shù)問題

跨節(jié)點多庫進行查詢時，會出現(xiàn)limit分頁、order by排序等問題。分頁需要按照指定字段進行排序，當排序字段就是分片字段時，通過分片規(guī)則就比較容易定位到指定的分片；當排序字段非分片字段時，就變得比較復雜了。需要先在不同的分片節(jié)點中將數(shù)據(jù)進行排序并返回，然后將不同分片返回的結(jié)果集進行匯總和再次排序，最終返回給用戶。如圖所示：

上圖中只是取第一頁的數(shù)據(jù)，對性能影響還不是很大。但是如果取得頁數(shù)很大，情況則變得復雜很多，因為各分片節(jié)點中的數(shù)據(jù)可能是隨機的，為了排序的準確性，需要將所有節(jié)點的前N頁數(shù)據(jù)都排序好做合并，最后再進行整體的排序，這樣的操作時很耗費CPU和內(nèi)存資源的，所以頁數(shù)越大，系統(tǒng)的性能也會越差。

在使用Max、Min、Sum、Count之類的函數(shù)進行計算的時候，也需要先在每個分片上執(zhí)行相應的函數(shù)，然后將各個分片的結(jié)果集進行匯總和再次計算，最終將結(jié)果返回。如圖所示：

4、全局主鍵避重問題

在分庫分表環(huán)境中，由于表中數(shù)據(jù)同時存在不同數(shù)據(jù)庫中，主鍵值平時使用的自增長將無用武之地，某個分區(qū)數(shù)據(jù)庫自生成的ID無法保證全局唯一。因此需要單獨設計全局主鍵，以避免跨庫主鍵重復問題。有一些常見的主鍵生成策略：

1）UUID

UUID標準形式包含32個16進制數(shù)字，分為5段，形式為8-4-4-4-12的36個字符，例如：550e8400-e29b-41d4-a716-446655440000

UUID是主鍵是最簡單的方案，本地生成，性能高，沒有網(wǎng)絡耗時。但缺點也很明顯，由于UUID非常長，會占用大量的存儲空間；另外，作為主鍵建立索引和基于索引進行查詢時都會存在性能問題，在InnoDB下，UUID的無序性會引起數(shù)據(jù)位置頻繁變動，導致分頁。

2）結(jié)合數(shù)據(jù)庫維護主鍵ID表

在數(shù)據(jù)庫中建立 sequence 表：

CREATE TABLE `sequence` ( `id` bigint(20) unsigned NOT NULL auto_increment, `stub` char(1) NOT NULL default '', PRIMARY KEY (`id`), UNIQUE KEY `stub` (`stub`) ) ENGINE=MyISAM;

stub字段設置為唯一索引，同一stub值在sequence表中只有一條記錄，可以同時為多張表生成全局ID。sequence表的內(nèi)容，如下所示：

+-------------------+------+ | id | stub | +-------------------+------+ | 72157623227190423 | a | +-------------------+------+

使用 MyISAM 存儲引擎而不是 InnoDB，以獲取更高的性能。MyISAM使用的是表級別的鎖，對表的讀寫是串行的，所以不用擔心在并發(fā)時兩次讀取同一個ID值。

當需要全局唯一的64位ID時，執(zhí)行：

REPLACE INTO sequence (stub) VALUES ('a'); SELECT LAST_INSERT_ID();

這兩條語句是Connection級別的，select last_insert_id() 必須與 replace into 在同一數(shù)據(jù)庫連接下才能得到剛剛插入的新ID。

使用replace into代替insert into好處是避免了表行數(shù)過大，不需要另外定期清理。

此方案較為簡單，但缺點也明顯：存在單點問題，強依賴DB，當DB異常時，整個系統(tǒng)都不可用。配置主從可以增加可用性，但當主庫掛了，主從切換時，數(shù)據(jù)一致性在特殊情況下難以保證。另外性能瓶頸限制在單臺MySQL的讀寫性能。

flickr團隊使用的一種主鍵生成策略，與上面的sequence表方案類似，但更好的解決了單點和性能瓶頸的問題。

這一方案的整體思想是：建立2個以上的全局ID生成的服務器，每個服務器上只部署一個數(shù)據(jù)庫，每個庫有一張sequence表用于記錄當前全局ID。表中ID增長的步長是庫的數(shù)量，起始值依次錯開，這樣能將ID的生成散列到各個數(shù)據(jù)庫上。如下圖所示：

由兩個數(shù)據(jù)庫服務器生成ID，設置不同的auto_increment值。第一臺sequence的起始值為1，每次步長增長2，另一臺的sequence起始值為2，每次步長增長也是2。結(jié)果第一臺生成的ID都是奇數(shù)（1, 3, 5, 7 ...），第二臺生成的ID都是偶數(shù)（2, 4, 6, 8 ...）。

這種方案將生成ID的壓力均勻分布在兩臺機器上。同時提供了系統(tǒng)容錯，第一臺出現(xiàn)了錯誤，可以自動切換到第二臺機器上獲取ID。但有以下幾個缺點：系統(tǒng)添加機器，水平擴展時較復雜；每次獲取ID都要讀寫一次DB，DB的壓力還是很大，只能靠堆機器來提升性能。

可以基于flickr的方案繼續(xù)優(yōu)化，使用批量的方式降低數(shù)據(jù)庫的寫壓力，每次獲取一段區(qū)間的ID號段，用完之后再去數(shù)據(jù)庫獲取，可以大大減輕數(shù)據(jù)庫的壓力。如下圖所示：

還是使用兩臺DB保證可用性，數(shù)據(jù)庫中只存儲當前的最大ID。ID生成服務每次批量拉取6個ID，先將max_id修改為5，當應用訪問ID生成服務時，就不需要訪問數(shù)據(jù)庫，從號段緩存中依次派發(fā)0~5的ID。當這些ID發(fā)完后，再將max_id修改為11，下次就能派發(fā)6~11的ID。于是，數(shù)據(jù)庫的壓力降低為原來的1/6。

3）Snowflake分布式自增ID算法

Twitter的snowflake算法解決了分布式系統(tǒng)生成全局ID的需求，生成64位的Long型數(shù)字，組成部分：

• 第一位未使用
• 接下來41位是毫秒級時間，41位的長度可以表示69年的時間
• 5位datacenterId，5位workerId。10位的長度最多支持部署1024個節(jié)點
• 最后12位是毫秒內(nèi)的計數(shù)，12位的計數(shù)順序號支持每個節(jié)點每毫秒產(chǎn)生4096個ID序列

這樣的好處是：毫秒數(shù)在高位，生成的ID整體上按時間趨勢遞增；不依賴第三方系統(tǒng)，穩(wěn)定性和效率較高，理論上QPS約為409.6w/s（1000*2^12），并且整個分布式系統(tǒng)內(nèi)不會產(chǎn)生ID碰撞；可根據(jù)自身業(yè)務靈活分配bit位。

不足就在于：強依賴機器時鐘，如果時鐘回撥，則可能導致生成ID重復。

綜上

結(jié)合數(shù)據(jù)庫和snowflake的唯一ID方案，可以參考業(yè)界較為成熟的解法：Leaf——美團點評分布式ID生成系統(tǒng)，并考慮到了高可用、容災、分布式下時鐘等問題。

5、數(shù)據(jù)遷移、擴容問題

當業(yè)務高速發(fā)展，面臨性能和存儲的瓶頸時，才會考慮分片設計，此時就不可避免的需要考慮歷史數(shù)據(jù)遷移的問題。一般做法是先讀出歷史數(shù)據(jù)，然后按指定的分片規(guī)則再將數(shù)據(jù)寫入到各個分片節(jié)點中。此外還需要根據(jù)當前的數(shù)據(jù)量和QPS，以及業(yè)務發(fā)展的速度，進行容量規(guī)劃，推算出大概需要多少分片（一般建議單個分片上的單表數(shù)據(jù)量不超過1000W）

如果采用數(shù)值范圍分片，只需要添加節(jié)點就可以進行擴容了，不需要對分片數(shù)據(jù)遷移。如果采用的是數(shù)值取模分片，則考慮后期的擴容問題就相對比較麻煩。

三. 什么時候考慮切分

下面講述一下什么時候需要考慮做數(shù)據(jù)切分。

1、能不切分盡量不要切分

并不是所有表都需要進行切分，主要還是看數(shù)據(jù)的增長速度。切分后會在某種程度上提升業(yè)務的復雜度，數(shù)據(jù)庫除了承載數(shù)據(jù)的存儲和查詢外，協(xié)助業(yè)務更好的實現(xiàn)需求也是其重要工作之一。

不到萬不得已不用輕易使用分庫分表這個大招，避免"過度設計"和"過早優(yōu)化"。分庫分表之前，不要為分而分，先盡力去做力所能及的事情，例如：升級硬件、升級網(wǎng)絡、讀寫分離、索引優(yōu)化等等。當數(shù)據(jù)量達到單表的瓶頸時候，再考慮分庫分表。

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

這里說的運維，指：

1）對數(shù)據(jù)庫備份，如果單表太大，備份時需要大量的磁盤IO和網(wǎng)絡IO。例如1T的數(shù)據(jù)，網(wǎng)絡傳輸占50MB時候，需要20000秒才能傳輸完畢，整個過程的風險都是比較高的

2）對一個很大的表進行DDL修改時，MySQL會鎖住全表，這個時間會很長，這段時間業(yè)務不能訪問此表，影響很大。如果使用pt-online-schema-change，使用過程中會創(chuàng)建觸發(fā)器和影子表，也需要很長的時間。在此操作過程中，都算為風險時間。將數(shù)據(jù)表拆分，總量減少，有助于降低這個風險。

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

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

舉個例子，假如項目一開始設計的用戶表如下：

id bigint #用戶的ID name varchar #用戶的名字 last_login_time datetime #最近登錄時間 personal_info text #私人信息 ..... #其他信息字段

在項目初始階段，這種設計是滿足簡單的業(yè)務需求的，也方便快速迭代開發(fā)。而當業(yè)務快速發(fā)展時，用戶量從10w激增到10億，用戶非常的活躍，每次登錄會更新 last_login_name 字段，使得 user 表被不斷update，壓力很大。而其他字段：id, name, personal_info 是不變的或很少更新的，此時在業(yè)務角度，就要將 last_login_time 拆分出去，新建一個 user_time 表。

personal_info 屬性是更新和查詢頻率較低的，并且text字段占據(jù)了太多的空間。這時候，就要對此垂直拆分出 user_ext 表了。

4、數(shù)據(jù)量快速增長

隨著業(yè)務的快速發(fā)展，單表中的數(shù)據(jù)量會持續(xù)增長，當性能接近瓶頸時，就需要考慮水平切分，做分庫分表了。此時一定要選擇合適的切分規(guī)則，提前預估好數(shù)據(jù)容量

5、安全性和可用性

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

四. 支持分庫分表中間件

站在巨人的肩膀上能省力很多，目前分庫分表已經(jīng)有一些較為成熟的開源解決方案：

• sharding-jdbc（當當）
• TSharding（蘑菇街）
• Atlas（奇虎360）
• Cobar（阿里巴巴）
• MyCAT（基于Cobar）
• Oceanus（58同城）
• Vitess（谷歌）

ps:看更多干貨，加入技術交流微信群可以關注我的公眾號360linker

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的tp 数据库查询排序_怎么进行数据库分库分表？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。