mysql分庫分表后，跨庫跨表搜索如何排序？mysql分為數(shù)據(jù)庫和表后，跨數(shù)據(jù)庫和跨表搜索如何排序？在單個(gè)表中處理大量數(shù)據(jù)是一種非常常見的。比如我們的訂單表，一般情況下，我們會(huì)按照一個(gè)月、三個(gè)月、六個(gè)

mysql分庫分表后，跨庫跨表搜索如何排序？

mysql分為數(shù)據(jù)庫和表后，跨數(shù)據(jù)庫和跨表搜索如何排序？在單個(gè)表中處理大量數(shù)據(jù)是一種非常常見的。比如我們的訂單表，一般情況下，我們會(huì)按照一個(gè)月、三個(gè)月、六個(gè)月以上的維度來劃分運(yùn)單表，自然也會(huì)按照時(shí)間來橫向劃分訂單表。

在這種情況下，子倉(cāng)庫和子表非常容易處理，因?yàn)槲覀兛梢愿鶕?jù)時(shí)間軸強(qiáng)制將訂單存儲(chǔ)在不同的倉(cāng)庫中。但是，有可能我們的電商系統(tǒng)用戶量大，訂單量大。一天有幾十萬單?？赡芏潭贪雮€(gè)月，我們的訂單量就上千萬了。加上訂單的商品數(shù)據(jù)表，如果沒有表，訂單表可能會(huì)拖累系統(tǒng)。

那么我們必須面對(duì)的是，一個(gè)月內(nèi)的數(shù)據(jù)要按照一定的規(guī)則劃分到不同的數(shù)據(jù)庫和表格中。我們可以把訂單表分成兩部分，OrderDB1和OrderDB2，根據(jù)我們的訂單號(hào)來區(qū)分。如果訂單號(hào)是單數(shù)，我們就放在OrderDB1，如果訂單號(hào)是偶數(shù)，我們就放在OrderDB2。這樣訂單表的數(shù)據(jù)均勻分布到兩個(gè)數(shù)據(jù)庫的表中，減少了單個(gè)表的壓力。

在此之后，我們的訂單表將很難按頁面排序。兩個(gè)數(shù)據(jù)庫中的數(shù)據(jù)如何跨數(shù)據(jù)庫按頁排序？

一般我們有三種方法，即全局視覺模式、容許精度損失模式和二次搜索模式。

讓 讓我們先談?wù)勅忠晥D模式。通常我們要在第三頁找到100個(gè)訂單的數(shù)據(jù)，我們會(huì)寫一個(gè)SQL。

select * from t order by time offset 200 limit 100。但是這100條數(shù)據(jù)分庫后可能會(huì)有很多辦法。

它可能是均勻分布的(在極端情況下)

也有可能都來自一個(gè)庫(極端情況下)。

它也可能是分散的(通常)

因?yàn)榘凑瘴覀兊腛rder By條件有很多可能，所以我們很難知道第三頁的數(shù)據(jù)是從哪個(gè)庫的哪里開始取的。如果我們需要準(zhǔn)確地獲得數(shù)據(jù)，那么我們必須恢復(fù)單個(gè)庫的全局視野。

如何恢復(fù)全球視野？

讓 讓我們以第三頁上我們要查詢的數(shù)據(jù)為例。我們失去全球視野的原因是我們可以 我們不可能一下子得到所有的數(shù)據(jù)結(jié)果，所以恢復(fù)我們?nèi)蛞曇暗姆椒ň褪亲屛覀兊玫剿械臄?shù)據(jù)結(jié)果。所以我們可以在兩個(gè)庫中查詢第一頁到第三頁的所有數(shù)據(jù)，然后在內(nèi)存中合并排序，然后從第三頁就可以得到正確的數(shù)據(jù)。

自然地，我們的sql也發(fā)生了變化，從

通過時(shí)間偏移200 li從T訂單中選擇*麻省理工100改成了

select * from t order by time offset 0 limit 100 200使用全局視圖模式的好處很明顯，就是數(shù)據(jù)絕對(duì)準(zhǔn)確。但是，缺點(diǎn)也很明顯。當(dāng)查詢數(shù)據(jù)較大時(shí)，內(nèi)存消耗會(huì)增加，當(dāng)頁數(shù)增加時(shí)，查詢效率會(huì)迅速下降。當(dāng)我們有N個(gè)數(shù)據(jù)庫時(shí)，我們需要查詢從X到X Y的數(shù)據(jù)，那么我們需要在內(nèi)存中組合N*(X Y)條數(shù)據(jù)，并對(duì)它們進(jìn)行排序。

既然全局查詢方法有缺點(diǎn)，我們會(huì)解決這個(gè)缺點(diǎn)，但是肯定會(huì)有一些其他的犧牲。

允許精度損失的方法其實(shí)很好理解，就是I don 我不關(guān)心數(shù)據(jù)在兩個(gè)數(shù)據(jù)庫中是如何分布的。我只是從兩個(gè)數(shù)據(jù)庫中平均整理出50條數(shù)據(jù)，然后組合成100條進(jìn)行展示。

當(dāng)然，這種方法的準(zhǔn)確性會(huì)根據(jù)你的排序條件和數(shù)據(jù)存儲(chǔ)而有所不同。假設(shè)我們的數(shù)據(jù)是按時(shí)間順序存儲(chǔ)的，我們的排序也是基于時(shí)間的，那么我們得到的結(jié)果會(huì)更準(zhǔn)確。

然而，如果我們的數(shù)據(jù)被隨機(jī)插入多個(gè)數(shù)據(jù)庫 s，我們要按時(shí)間排序和搜索，或者我們的數(shù)據(jù)是按時(shí)間順序插入DB的，但是當(dāng)我們需要按其他條件搜索時(shí)，數(shù)據(jù)的準(zhǔn)確性就會(huì)很差。這取決于我們的業(yè)務(wù)需求是什么。

然而，用這種方法搜索，我們不 不必考慮性能問題，并且查詢的復(fù)雜性非常低。只要我們的業(yè)務(wù)沒有太多的要求，那么使用這種方法是最推薦的。

當(dāng)然，如果你的業(yè)務(wù)不允許這種情況發(fā)生，你還需要滿足交互、效率等各種需求，那么我們也可以使用下面的方法。

第二種查詢模式可以說是解決子庫查詢的終極武器，可以保證數(shù)據(jù)的準(zhǔn)確性、查詢的效率和用戶的交互頁面，代價(jià)只是很小的性能開銷和一定的代碼難度。

其實(shí)方法并不難。假設(shè)我們想查詢第21頁的數(shù)據(jù)，每頁5篇文章。在這個(gè)時(shí)候，讓 假設(shè)數(shù)據(jù)是均勻分布的，但是我們查詢每個(gè)庫中的全部5條數(shù)據(jù)。那就是:

select * from T order by time offset 100限制5

這個(gè)時(shí)候我們得到的數(shù)據(jù)可能是這樣的。

兩個(gè)db中，時(shí)間最短的是1487500001【minTime】，記錄了這個(gè)時(shí)間。還記錄了兩個(gè)db中的最大時(shí)間，即db1: 1487500041 [maxtime1]和DB2: 1487500061 [maxtime2]。

這時(shí)候我們?cè)谑褂脮r(shí)間內(nèi)再去兩個(gè)數(shù)據(jù)庫查詢。

挑選* from t where time between minTime and maxtime 1 order by time select * from t where time between minTime and maxtime 2 order by time由于之前minTime來自DB1，所以DB1的數(shù)據(jù)不會(huì)改變，但是DB2中的條件放寬了，所以可能會(huì)查詢到更多的數(shù)據(jù)。結(jié)果可能如下:

兩個(gè)結(jié)果合并后，相當(dāng)于得到了一個(gè)全局視圖，很容易就能找出這個(gè)頁面需要的五條數(shù)據(jù)。

當(dāng)然我們也可以使用elasticsearch來完成子數(shù)據(jù)庫的排序搜索，因?yàn)閑lasticsearch引入了緩存機(jī)制，可以讓查詢更快。

mysql數(shù)據(jù)庫分庫分表后要是有跨表的查詢?cè)趺刺幚?，分頁的時(shí)候怎么處理？

可以先統(tǒng)計(jì)子表，再根據(jù)頁數(shù)獲取數(shù)據(jù)，或者使用中間件獲取數(shù)據(jù)。mysql數(shù)據(jù)庫分表后，如何處理跨表查詢，分頁時(shí)如何處理。