mysqljoin后如何分頁？1. 右鍵表，打開右鍵菜單列表，點(diǎn)擊設(shè)計(jì)表，進(jìn)入到設(shè)計(jì)表窗口，點(diǎn)擊索引，進(jìn)入到索引窗口完成主鍵索引的設(shè)置，2. 然后在使用SELECT * FROM tmysql分庫分表

mysqljoin后如何分頁？

1. 右鍵表，打開右鍵菜單列表，點(diǎn)擊設(shè)計(jì)表，進(jìn)入到設(shè)計(jì)表窗口，點(diǎn)擊索引，進(jìn)入到索引窗口完成主鍵索引的設(shè)置，

2. 然后在使用SELECT * FROM t

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

mysql分庫分表后，跨庫跨表搜索如何排序？數(shù)據(jù)庫分庫分表可以說是非常常見的一種應(yīng)對單表數(shù)據(jù)量過大的手段了。例如：我們的訂單表，通常情況下，我們會(huì)將運(yùn)單表按照1個(gè)月、3個(gè)月、6個(gè)月以上的維度進(jìn)行劃分，自然也就會(huì)按照時(shí)間進(jìn)行訂單表的水平切分。

這種情況下的分庫分表非常好處理，因?yàn)槲覀兡軌驈?qiáng)制的按照時(shí)間線將訂單存儲(chǔ)到不同的庫中。但是，有可能我們的電商系統(tǒng)用戶量大，訂單量多，一天就有幾十萬單，可能僅僅半個(gè)月，我們的訂單量就會(huì)上千萬，再加上訂單的商品數(shù)據(jù)表，如果不分表，訂單表可能就會(huì)把系統(tǒng)給拖垮。

那么我們就必須面臨將1個(gè)月內(nèi)的數(shù)據(jù)也要按照一定的規(guī)則進(jìn)行分庫分表。我們可以將訂單表一分為二，分為了OrderDB1，OrderDB2，按照我們按照訂單號(hào)來進(jìn)行區(qū)分。訂單號(hào)是單數(shù)，我們就放到OrderDB1中，訂單號(hào)是雙數(shù)，我們就放到OrderDB2中。如此一來，訂單表的數(shù)據(jù)就被平均的分配到了兩個(gè)數(shù)據(jù)庫的表中了，單表的壓力也就降低了。

而這樣分庫分表以后，我們的訂單表如果需要進(jìn)行分頁的排序就非常困難了，兩個(gè)數(shù)據(jù)庫中的數(shù)據(jù)如何進(jìn)行跨庫的分頁排序查詢呢？

一般我們有三種方法，分別是：全局視野、允許精度損失、二次查找。

先說全局視野通常情況下我們要查找第三頁的100條訂單數(shù)據(jù)，我們會(huì)寫一個(gè)SQL

select * from T order by time offset 200 limit 100但是分庫以后，這100條數(shù)據(jù)可能存在很多種。

有可能是平均分布（極端情況）

也有可能是全部來自一個(gè)庫（極端情況）

還有可能是散亂分布的（通常情況）

由于情況根據(jù)我們的Order By條件有很多的可能，所以我們很難知道第三頁的數(shù)據(jù)到底從哪個(gè)庫的哪個(gè)位置開始取數(shù)。如果我們需要精準(zhǔn)的取到數(shù)據(jù)，那么就必須重新還原單庫的那種全局視野。

如何還原全局視野呢？

還是用我們要查詢第三頁的數(shù)據(jù)來舉例，我們之所以失去了全局視野，是因?yàn)槲覀儫o法一次性得到所有的數(shù)據(jù)結(jié)果，那么還原全局視野的就是讓我們能夠得到所有的數(shù)據(jù)結(jié)果。因此，我們可以將兩個(gè)庫中的從第一頁到第三頁的全部數(shù)據(jù)查詢出來，然后在內(nèi)存中合并后再進(jìn)行排序，然后就能夠取出正確的第三頁數(shù)據(jù)了。

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

select * from T order by time offset 200 limit 100改為

select * from T order by time offset 0 limit 100 200使用全局視野的好處很明顯，就是數(shù)據(jù)絕對的精準(zhǔn)。但是缺點(diǎn)也同樣明顯，當(dāng)查詢的數(shù)據(jù)量大時(shí)，內(nèi)存的消耗就會(huì)變多，而且在頁碼增大的時(shí)候，查詢效率會(huì)急速的下降。當(dāng)我們有N個(gè)數(shù)據(jù)庫，我們需要從查詢X到X Y區(qū)間的數(shù)據(jù)時(shí)，那么我們的內(nèi)存中將會(huì)需要組合N*(X Y)條數(shù)據(jù)然后排序。

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

允許精度損失允許精度損失其實(shí)非常的好理解，就是我不去管數(shù)據(jù)在兩個(gè)DB中是如何的分布的，我只是平均的從兩個(gè)庫中排序后取出50條數(shù)據(jù)，然后組合成為100條進(jìn)行顯示。

當(dāng)然，這種的精度就是根據(jù)你排序的條件和數(shù)據(jù)存儲(chǔ)的不同而變化的了。假設(shè)我們的數(shù)據(jù)都是按照時(shí)間有序的存儲(chǔ)的，我們的排序也是根據(jù)時(shí)間來進(jìn)行排序的，那么我們得到的結(jié)果就會(huì)比較精準(zhǔn)。

但如果我們的數(shù)據(jù)是隨機(jī)插入多個(gè)DB的，我們要按照時(shí)間進(jìn)行排序查找，或者我們的數(shù)據(jù)是按照時(shí)間順序插入DB的，但是我們需要根據(jù)其他條件進(jìn)行查找時(shí)，數(shù)據(jù)的精度就會(huì)很差。這就看我們對于業(yè)務(wù)的需要是什么樣的了。

不過，使用這種查找，我們就可以不用考慮性能上的問題，查詢的復(fù)雜程度很低，只要我們的業(yè)務(wù)沒有過多的要求，那么使用這種查找是最為推薦的。

當(dāng)然，如果你的業(yè)務(wù)不允許這樣的情況出現(xiàn)，還需要滿足交互、效率等等各種需求，那么，就我們還可以使用下面這個(gè)。

二次查詢這可以說是解決分庫查詢的究極武器了，能夠保證數(shù)據(jù)的精準(zhǔn)度、查詢的效率、用戶的交互頁面，犧牲的只是小小的性能開銷和一些代碼難度的上升。

其實(shí)也不難，假設(shè)我們要查詢第21頁的數(shù)據(jù)，每頁5條。這個(gè)時(shí)候，我們先假設(shè)數(shù)據(jù)是平均分布的，但是我們在每個(gè)庫都查詢?nèi)康?條數(shù)據(jù)。也就是：

select * from T order by time offset 100 limit 5

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

而兩個(gè)DB中，最小的時(shí)間是1487500001【minTime】，這個(gè)時(shí)間記錄下來。兩個(gè)DB中各自的最大時(shí)間也記錄下來，分別是DB1：1487500041【maxTime1】 和 DB2：1487500061【maxTime2】。

這時(shí)，我們在使用時(shí)間去兩個(gè)數(shù)據(jù)庫中再次進(jìn)行查詢。

select * from T where time between minTime and maxTime1 order by time select * from T where time between minTime and maxTime2 order by time由于之前minTime來自于DB1，因此，DB1的數(shù)據(jù)不會(huì)發(fā)生變化，但是DB2中的條件被放寬了，因此可能會(huì)查詢出更多的數(shù)據(jù)。結(jié)果可能如下：

而兩個(gè)結(jié)果集合并以后，相當(dāng)于就獲得了全局視野，也就可以很容易的找出這一頁需要的5條數(shù)據(jù)了。

當(dāng)然，我們還可以借助elasticsearch來完成分庫的排序查找，由于elasticsearch引入了緩存機(jī)制，能夠讓查詢更快。