小明是一家初創(chuàng)電商平臺(tái)的開(kāi)發(fā)人員，他負(fù)責(zé)賣(mài)家模塊的功能開(kāi)發(fā)，其中涉及了店鋪、商品的相關(guān)業(yè)務(wù)，設(shè)計(jì)如下數(shù)據(jù)庫(kù) ：
通過(guò)以下SQL能夠獲取到商品相關(guān)的店鋪信息、地理區(qū)域信息 ： SELECT p.*,r.[地理區(qū)域名稱],s.[店鋪名稱],s.[信譽(yù)] FROM [商品信息] p
LEFT JOIN [地理區(qū)域] r ON p.[產(chǎn)地] = r.[地理區(qū)域編碼] LEFT JOIN [店鋪信息] s ON p.id = s.[所屬店鋪]
WHERE p.id = ? 形成類(lèi)似以下列表展示 ：
隨著公司業(yè)務(wù)快速發(fā)展，數(shù)據(jù)庫(kù)中的數(shù)據(jù)量猛增，訪問(wèn)性能也變慢了，優(yōu)化迫在眉睫。分析一下問(wèn)題出現(xiàn)在哪兒 呢? 關(guān)系型數(shù)據(jù)庫(kù)本身比較容易成為系統(tǒng)瓶頸，單機(jī)存儲(chǔ)容量、連接數(shù)、處理能力都有限。當(dāng)單表的數(shù)據(jù)量達(dá)到 1000W或100G以后，由于查詢維度較多，即使添加從庫(kù)、優(yōu)化索引，做很多操作時(shí)性能仍下降嚴(yán)重。
方案1:
通過(guò)提升服務(wù)器硬件能力來(lái)提高數(shù)據(jù)處理能力，比如增加存儲(chǔ)容量 、CPU等，這種方案成本很高，并且如果瓶頸在
MySQL本身那么提高硬件也是有很的。
方案2:
把數(shù)據(jù)分散在不同的數(shù)據(jù)庫(kù)中，使得單一數(shù)據(jù)庫(kù)的數(shù)據(jù)量變小來(lái)緩解單一數(shù)據(jù)庫(kù)的性能問(wèn)題，從而達(dá)到提升數(shù)據(jù)庫(kù) 性能的目的，如下圖:將電商數(shù)據(jù)庫(kù)拆分為若干獨(dú)立的數(shù)據(jù)庫(kù)，并且對(duì)于大表也拆分為若干小表，通過(guò)這種數(shù)據(jù)庫(kù) 拆分的方法來(lái)解決數(shù)據(jù)庫(kù)的性能問(wèn)題。
分庫(kù)分表就是為了解決由于數(shù)據(jù)量過(guò)大而導(dǎo)致數(shù)據(jù)庫(kù)性能降低的問(wèn)題，將原來(lái)獨(dú)立的數(shù)據(jù)庫(kù)拆分成若干數(shù)據(jù)庫(kù)組成，將數(shù)據(jù)大表分成若干數(shù)據(jù)表組成，使得單一數(shù)據(jù)庫(kù)、單一數(shù)據(jù)表的數(shù)據(jù)量變小，從而達(dá)到提升數(shù)據(jù)庫(kù)性能的目的。 分庫(kù)分表包括分庫(kù)和分表兩個(gè)部分，在生產(chǎn)中通常包括 ：垂直分庫(kù)、水平分庫(kù)、垂直分表、水平分表四種方式。 下邊通過(guò)一個(gè)商品查詢的案例來(lái)垂直分表 ：
通常在商品列表中是不是顯示商品詳情信息的，如下圖 ：
用戶在瀏覽商品列表時(shí)，只有對(duì)某商品感興趣時(shí)才會(huì)查看商品的詳細(xì)描述。因此，商品信息中商品描述字段訪問(wèn)頻次較低，且該字段存儲(chǔ)占用空間較大，訪問(wèn)單個(gè)數(shù)據(jù)IO時(shí)間較長(zhǎng)；商品信息中商品名稱、商品圖片、商品價(jià)格等其他字段數(shù)據(jù)訪問(wèn)頻次較高。
由于這兩種數(shù)據(jù)的特性不一樣，因此他考慮將商品信息表拆分如下 ：
將訪問(wèn)頻次低的商品描述信息單獨(dú)存放在一張表中，訪問(wèn)頻次較高的商品基本信息單獨(dú)放在一張表中。
商品列表可采用以下sql ： SELECT p.*,r.[地理區(qū)域名稱],s.[店鋪名稱],s.[信譽(yù)] FROM [商品信息] p
LEFT JOIN [地理區(qū)域] r ON p.[產(chǎn)地] = r.[地理區(qū)域編碼] LEFT JOIN [店鋪信息] s ON p.id = s.[所屬店鋪] WHERE...ORDER BY...LIMIT... 需要獲取商品描述時(shí)，再通過(guò)以下sql獲取 ： SELECT *
FROM [商品描述] WHERE [商品ID] = ? 小明進(jìn)行的這一步優(yōu)化，就叫垂直分表。
垂直分表定義 ：將一個(gè)表按照字段分成多表，每個(gè)表存儲(chǔ)其中一部分字段。
它帶來(lái)的提升是 ：
1.為了避免IO爭(zhēng)搶并減少鎖表的幾率，查看詳情的用戶與商品信息瀏覽互不影響。
2.充分發(fā)揮熱門(mén)數(shù)據(jù)的操作效率，商品信息的操作的高效率不會(huì)被商品描述的低效率所拖累。
注意 ：
為什么大字段IO效率低 ：
第一是由于數(shù)據(jù)量本身大，需要更長(zhǎng)的讀取時(shí)間；
第二是跨頁(yè)，頁(yè)是數(shù)據(jù)庫(kù)存儲(chǔ)單位，很多查找及定位操作都是以頁(yè)為單位，單頁(yè)內(nèi)的數(shù)據(jù)行越多數(shù)據(jù)庫(kù)整體性能越好，而大字段占用空間大，單頁(yè)內(nèi)存儲(chǔ)行數(shù)少，因此IO效率較低。
第三，數(shù)據(jù)庫(kù)以行為單位將數(shù)據(jù)加載到內(nèi)存中，這樣表中字段長(zhǎng)度較短且訪問(wèn)頻率較高，內(nèi)存能加載更多的數(shù)據(jù)，命中率更高，減少來(lái)磁盤(pán)IO，從而提升來(lái)數(shù)據(jù)庫(kù)性能。
一般來(lái)說(shuō)，某業(yè)務(wù)實(shí)體中的各個(gè)數(shù)據(jù)項(xiàng)的訪問(wèn)頻次是不一樣的，部分?jǐn)?shù)據(jù)項(xiàng)可能是占用存儲(chǔ)空間比較大的BLOB或是TEXT。例如上例中的商品描述。所以，當(dāng)表數(shù)據(jù)量很大時(shí)，可以將表按字段切開(kāi)，將熱門(mén)字段、冷門(mén)字段分開(kāi)放置在不同庫(kù)中，這些庫(kù)可以放在不同的存儲(chǔ)設(shè)置上，避免IO爭(zhēng)搶。垂直切分帶來(lái)的性能提升主要集中在熱門(mén)數(shù)據(jù)的操作效率上，而且磁盤(pán)爭(zhēng)用情況減少。
通常我們按以下原則進(jìn)行垂直拆分 ：
1、把不常用的字段單獨(dú)放在一張表；
2、把text，blob等大字段拆分出來(lái)放在附表中；
3、經(jīng)常組合查詢的列放在一張表中； 通過(guò)垂直分表能得到來(lái)一定程度的提升，但是還沒(méi)有達(dá)到要求，并且磁盤(pán)空間也快不夠來(lái)，因?yàn)閿?shù)據(jù)還是始終限制在一臺(tái)服務(wù)器，庫(kù)內(nèi)垂直分表只解決來(lái)單一表數(shù)據(jù)量過(guò)大的問(wèn)題，但沒(méi)有將表分布到不同的服務(wù)器上，因此每個(gè)表還是競(jìng)爭(zhēng)同一個(gè)物理機(jī)的CPU、內(nèi)存、網(wǎng)絡(luò)IO
、磁盤(pán)。
經(jīng)過(guò)思考，他把原來(lái)的SELLER_DB（賣(mài)家?guī)欤?，分為?lái)PRODUCT_DB (商品庫(kù))和STORE_DB（店鋪庫(kù)），并把這兩個(gè)庫(kù)分散到不同服務(wù)器，如下圖 ：
由于商品信息與商品描述業(yè)務(wù)耦合度較高，因此一起被存放在PRODUCT_DB（商品庫(kù)）；而店鋪信息相對(duì)獨(dú)立，因此單獨(dú)被存放在STORE_DB（店鋪庫(kù)）。
小明進(jìn)行的這一步優(yōu)化，就叫垂直分庫(kù)。
垂直分庫(kù)是指按照業(yè)務(wù)將表進(jìn)行分類(lèi)，分布到不同的數(shù)據(jù)庫(kù)上面，每個(gè)庫(kù)可以放不同的服務(wù)器上，它的核心理念是專(zhuān)庫(kù)專(zhuān)用。
它帶來(lái)的提升是 ： 解決業(yè)務(wù)層面的耦合，業(yè)務(wù)清晰 能對(duì)不同業(yè)務(wù)的數(shù)據(jù)進(jìn)行分級(jí)管理、維護(hù)、監(jiān)控、擴(kuò)展等 高并發(fā)場(chǎng)景下，垂直分庫(kù)一定程度的提升IO、數(shù)據(jù)庫(kù)連接數(shù)、降低單機(jī)硬件資源的瓶頸
垂直分庫(kù)通過(guò)將表按業(yè)務(wù)分類(lèi)，然后分庫(kù)在不同數(shù)據(jù)庫(kù)，并且可以將這些數(shù)據(jù)庫(kù)部署在不同服務(wù)器上，從而達(dá)到多個(gè)服務(wù)器共同分?jǐn)倝毫Φ男Ч且廊粵](méi)有解決單表數(shù)據(jù)量過(guò)大的問(wèn)題。
經(jīng)過(guò)垂直分庫(kù)后，數(shù)據(jù)庫(kù)性能問(wèn)題得到一定程度的解決，但是隨著業(yè)務(wù)量的增長(zhǎng)，PRODUCT_DB（商品庫(kù)）單庫(kù)存儲(chǔ)數(shù)據(jù)已經(jīng)超出預(yù)估。粗糧統(tǒng)計(jì)，目前有8W店鋪，每個(gè)店鋪平均150個(gè)不同規(guī)格的商品，再算增長(zhǎng)，那商品數(shù)量的往1500w+上預(yù)估，并且PRODUCT_DB（商品庫(kù)）屬于訪問(wèn)非常頻繁的資源，單臺(tái)服務(wù)器已經(jīng)無(wú)法支撐。此時(shí)該如何優(yōu)化？
再次分庫(kù)？但是從業(yè)務(wù)角度分析，目前情況已經(jīng)無(wú)法再次垂直分庫(kù)?？梢試L試水平分庫(kù)，將店鋪ID為單數(shù)的和店鋪ID為雙數(shù)的商品信息分別放在兩個(gè)庫(kù)中。
也就是說(shuō)，要操作其某條數(shù)據(jù)，先分析這條數(shù)據(jù)所屬的店鋪ID。如果店鋪ID為雙數(shù)，將此操作映射至PRODUCT_DB1（商品庫(kù)1）；如果ID為單數(shù)，將操作映射至RRODUCT_DB2（商品庫(kù)2）。此操作要訪問(wèn)數(shù)據(jù)庫(kù)名稱的表達(dá)式為RRODUCT_DB【店鋪ID%2 + 1】.
小明進(jìn)行的這一步優(yōu)化，就叫水平分庫(kù)。
水平分庫(kù)是把同一個(gè)表的數(shù)據(jù)按一定規(guī)則拆分到不同的數(shù)據(jù)庫(kù)中，每個(gè)庫(kù)可以放不同的服務(wù)器上。
對(duì)比 ：垂直分庫(kù)是把不同表拆到不同數(shù)據(jù)庫(kù)中，它是對(duì)數(shù)據(jù)行的拆分，不影響表結(jié)構(gòu)。
它帶來(lái)的提升是 ： 解決來(lái)單庫(kù)大數(shù)據(jù)，高并發(fā)的性能瓶頸。 提高來(lái)系統(tǒng)的穩(wěn)定性及可用性。
穩(wěn)定性體現(xiàn)在IO沖突減少，鎖定減少，可用性指某個(gè)庫(kù)出問(wèn)題，部分可用。
當(dāng)一個(gè)應(yīng)用難以再細(xì)粒度的垂直切分，或切分后數(shù)據(jù)量行巨大，存在單庫(kù)讀寫(xiě)、存儲(chǔ)性能瓶頸，這時(shí)候就需要進(jìn)行水平分庫(kù)了，經(jīng)過(guò)水平切分的優(yōu)化，往往能解決單庫(kù)存儲(chǔ)量及性能瓶頸。但由于同一個(gè)表被分配在不同的數(shù)據(jù)庫(kù)，需要額外進(jìn)行數(shù)據(jù)操作的路由工作，因此大大提升了系統(tǒng)復(fù)雜度。
按照水平分庫(kù)的思路對(duì)他把PRODUCT_DB_X（商品庫(kù)）內(nèi)的表也可以進(jìn)行水平拆分，其目的也是為解決單表數(shù)據(jù)量大的問(wèn)題，如下圖 ：
與水平分庫(kù)的思路類(lèi)似，不過(guò)這次操作的目標(biāo)是表，商品信息及商品描述被分成了兩套表。如果商品ID為雙數(shù)，將此操作映射至商品信息1表；如果商品ID為單數(shù)，將操作映射至商品信息2表。此操作要訪問(wèn)表名稱的表達(dá)式為商品信息【商品ID%2 + 1】。
小明進(jìn)行的這一步優(yōu)化，就叫水平分表。
水平分表是在同一個(gè)數(shù)據(jù)庫(kù)內(nèi)，把同一個(gè)表的數(shù)據(jù)按一定規(guī)則拆到多個(gè)表中。
它帶來(lái)的提升是 ： 介紹來(lái)分庫(kù)分表的幾種方式，它們分別是垂直分表、垂直分庫(kù)、水平分庫(kù)和水平分表 ：
垂直分表 ：可以把一個(gè)寬表的字段按訪問(wèn)頻次，是否是大字段的原則拆分為多個(gè)表，這樣既能使業(yè)務(wù)清晰，還能提升部分性能。拆分后，盡量從業(yè)務(wù)角度避免聯(lián)查，否則性能方面將得不償失。
垂直分庫(kù) ：可以把多個(gè)表按業(yè)務(wù)耦合松緊歸類(lèi)，分別存放在不同的庫(kù)，這些庫(kù)可以分布在不同服務(wù)器，從而使訪問(wèn)壓力被能服務(wù)器負(fù)載，大大提升性能，同時(shí)能提高整體架構(gòu)的業(yè)務(wù)清晰度，不同的業(yè)務(wù)庫(kù)可根據(jù)自身情況定制優(yōu)化方案。但是它需要解決跨庫(kù)帶來(lái)的所有復(fù)雜問(wèn)題。
水平分庫(kù) ：可以把一個(gè)表的數(shù)據(jù)（按數(shù)據(jù)行）分到多個(gè)不同的庫(kù)，每個(gè)庫(kù)只有這個(gè)表的部分?jǐn)?shù)據(jù)，這些庫(kù)可以分布在不同服務(wù)器，從而使訪問(wèn)壓力被多服務(wù)器負(fù)載，大大提升性能。它不僅需要解決跨庫(kù)帶來(lái)的所有復(fù)雜問(wèn)題，還要解決數(shù)據(jù)路由的問(wèn)題（數(shù)據(jù)路由問(wèn)題后邊介紹）。
水平分表 ：可以把一個(gè)表的數(shù)據(jù)（按數(shù)據(jù)行）分到多個(gè)同一個(gè)數(shù)據(jù)庫(kù)的多張表中，每個(gè)表只有這個(gè)表的部分?jǐn)?shù)據(jù)，這樣做能小幅提升性能，它僅僅作為水平分庫(kù)的一個(gè)補(bǔ)充優(yōu)化。
一般來(lái)說(shuō)，在系統(tǒng)設(shè)計(jì)階段就應(yīng)該根據(jù)業(yè)務(wù)耦合松緊來(lái)確定垂直分庫(kù)，垂直分表方案，在數(shù)據(jù)量及訪問(wèn)壓力不是特別大的情況，首先考慮緩沖、讀寫(xiě)分離、索引技術(shù)等方案。若數(shù)據(jù)量極大，且持續(xù)增長(zhǎng)，再考慮水平分庫(kù)水平分表方案。 1.3.分庫(kù)分表帶來(lái)的問(wèn)題分庫(kù)分表能有效的緩解來(lái)單機(jī)和單庫(kù)帶來(lái)的性能瓶頸和壓力，突破網(wǎng)絡(luò)IO、硬件資源、連接數(shù)的瓶頸，同時(shí)也帶來(lái)了一些問(wèn)題。 由于分庫(kù)分表把數(shù)據(jù)分布在不同庫(kù)甚至不同服務(wù)器，不可避免會(huì)帶來(lái)分布式事務(wù)問(wèn)題。 1.3.2.跨節(jié)點(diǎn)關(guān)聯(lián)查詢在沒(méi)有分庫(kù)前，我們檢索商品時(shí)可以通過(guò)以下SQL對(duì)店鋪信息進(jìn)行關(guān)聯(lián)查詢 ： SELECT p.*,r.[地理區(qū)域名稱],s.[店鋪名稱],s.[信譽(yù)] FROM [商品信息] p
LEFT JOIN [地理區(qū)域] r ON p.[產(chǎn)地] = r.[地理區(qū)域編碼] LEFT JOIN [店鋪信息] s ON p.id = s.[所屬店鋪] WHERE...ORDER BY...LIMIT... 但垂直分庫(kù)后【商品信息】和【店鋪信息】不在一個(gè)數(shù)據(jù)庫(kù)，甚至不在一臺(tái)服務(wù)器，無(wú)法進(jìn)行關(guān)聯(lián)查詢。
可將原關(guān)聯(lián)查詢分為兩次查詢，第一次查詢的結(jié)果集中找出關(guān)聯(lián)數(shù)據(jù)id，然后根據(jù)id發(fā)起第二次請(qǐng)求得到關(guān)聯(lián)數(shù)據(jù)，最后將獲得到的數(shù)據(jù)進(jìn)行拼裝。 1.3.3.跨節(jié)點(diǎn)分頁(yè)、排序函數(shù)跨節(jié)點(diǎn)多庫(kù)進(jìn)行查詢時(shí)，limit分頁(yè)、order by排序等問(wèn)題，就變得比較復(fù)雜了。需要先在不同的分片節(jié)點(diǎn)中將數(shù)據(jù)進(jìn)行排序并返回，然后將不同分片返回的結(jié)果集進(jìn)行匯總和再次排序。
如，進(jìn)行水平分庫(kù)后的商品庫(kù)，按ID倒序排序分頁(yè)，取第一頁(yè) ：
以上流程是取第一頁(yè)的數(shù)據(jù)，性能影響不大，但由于商品信息的分布在各數(shù)據(jù)庫(kù)的數(shù)據(jù)可能是隨機(jī)的，如果是取第N頁(yè)，需要將所有節(jié)點(diǎn)前N頁(yè)數(shù)據(jù)都取出來(lái)合并，再進(jìn)行整體的排序，操作效率可想而知。所以請(qǐng)求頁(yè)數(shù)越大，系統(tǒng)的性能也會(huì)越差。在使用Max、Min、Sum、Count之類(lèi)的函數(shù)進(jìn)行計(jì)算的時(shí)候，與排序分頁(yè)同理，也需要先在每個(gè)分片上執(zhí)行相應(yīng)的函數(shù)，然后將各個(gè)分片的結(jié)果集進(jìn)行匯總和再次計(jì)算，最終將結(jié)果返回。 在分庫(kù)分表環(huán)境中，由于表中數(shù)據(jù)同時(shí)存在不同數(shù)據(jù)庫(kù)中，主鍵值平時(shí)使用的自增長(zhǎng)將無(wú)用武之地，某個(gè)分區(qū)數(shù)據(jù)庫(kù)生成的ID無(wú)法保證全局唯一。因此需要單獨(dú)設(shè)計(jì)全局主鍵，比避免跨庫(kù)主鍵重復(fù)問(wèn)題。
 實(shí)際的應(yīng)用場(chǎng)景中，參數(shù)表、數(shù)據(jù)字典表等都是數(shù)據(jù)量較小，變動(dòng)少，而且屬于高頻聯(lián)合查詢的依賴表。例子中地理區(qū)域表也屬于此類(lèi)型。
可以將這類(lèi)表在每個(gè)數(shù)據(jù)庫(kù)都保存一份，所有對(duì)公共表的更新操作都同時(shí)發(fā)送到分庫(kù)執(zhí)行。
由于分庫(kù)分表之后，數(shù)據(jù)被分散在不同的數(shù)據(jù)庫(kù)、服務(wù)器。因此，對(duì)數(shù)據(jù)的操作也就無(wú)法通過(guò)常規(guī)方式完成，并且它還帶來(lái)了一系列的問(wèn)題。好在，這些問(wèn)題不是所有都需要我們?cè)趹?yīng)用層面上解決，其中Sharding-JDBC中間件可供選擇。 Sharding-JDBC是當(dāng)當(dāng)網(wǎng)研發(fā)的開(kāi)源分布式數(shù)據(jù)庫(kù)中間件，從 3.0 開(kāi)始Sharding-JDBC被包含在 Sharding-Sphere 中，之后該項(xiàng)目進(jìn)入進(jìn)入Apache孵化器，4.0版本之后的版本為Apache版本。
ShardingSphere是一套開(kāi)源的分布式數(shù)據(jù)庫(kù)中間件解決方案組成的生態(tài)圈，它由Sharding-JDBC、Sharding- Proxy和Sharding-Sidecar(計(jì)劃中)這3款相互獨(dú)立的產(chǎn)品組成。 他們均提供標(biāo)準(zhǔn)化的數(shù)據(jù)分片、分布式事務(wù)和 數(shù)據(jù)庫(kù)治理功能，可適用于如Java同構(gòu)、異構(gòu)語(yǔ)言、容器、云原生等各種多樣化的應(yīng)用場(chǎng)景。
官方地址:https://shardingsphere./document/current/cn/overview/
咱們目前只需關(guān)注Sharding-JDBC，它定位為輕量級(jí)Java框架，在Java的JDBC層提供的額外服務(wù)。 它使用客戶端 直連數(shù)據(jù)庫(kù)，以jar包形式提供服務(wù)，無(wú)需額外部署和依賴，可理解為增強(qiáng)版的JDBC驅(qū)動(dòng)，完全兼容JDBC和各種 ORM框架。
Sharding-JDBC的核心功能為數(shù)據(jù)分片和讀寫(xiě)分離，通過(guò)Sharding-JDBC，應(yīng)用可以透明的使用jdbc訪問(wèn)已經(jīng)分庫(kù) 分表、讀寫(xiě)分離的多個(gè)數(shù)據(jù)源，而不用關(guān)心數(shù)據(jù)源的數(shù)量以及數(shù)據(jù)如何分布。 適用于任何基于Java的ORM框架，如: Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。 基于任何第三方的數(shù)據(jù)庫(kù)連接池，如:DBCP, C3P0, BoneCP, Druid, HikariCP等。 支持任意實(shí)現(xiàn)JDBC規(guī)范的數(shù)據(jù)庫(kù)。目前支持MySQL，Oracle，SQLServer和PostgreSQL。
上圖展示了Sharding-Jdbc的工作方式，使用Sharding-Jdbc前需要人工對(duì)數(shù)據(jù)庫(kù)進(jìn)行分庫(kù)分表，在應(yīng)用程序中加入 Sharding-Jdbc的Jar包，應(yīng)用程序通過(guò)Sharding-Jdbc操作分庫(kù)分表后的數(shù)據(jù)庫(kù)和數(shù)據(jù)表，由于Sharding-Jdbc是對(duì) Jdbc驅(qū)動(dòng)的增強(qiáng)，使用Sharding-Jdbc就像使用Jdbc驅(qū)動(dòng)一樣，在應(yīng)用程序中是無(wú)需指定具體要操作的分庫(kù)和分表 的。
性能損耗測(cè)試 ：服務(wù)器資源充足、并發(fā)數(shù)相同，比較JDBC和Sharding-JDBC性能損耗，Sharding-JDBC相對(duì)JDBC損耗不超過(guò)7%。
基準(zhǔn)測(cè)試性能對(duì)比
性能對(duì)比測(cè)試:服務(wù)器資源使用到極限，相同的場(chǎng)景JDBC與Sharding-JDBC的吞吐量相當(dāng)。 性能對(duì)比測(cè)試:服務(wù)器資源使用到極限，Sharding-JDBC采用分庫(kù)分表后，Sharding-JDBC吞吐量較JDBC不分表有接近2倍的提升。
|
