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

mysqljoin后如何分頁？

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

2. 然后在使用SELECT * FROM t

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

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

這種情況下的分庫分表非常好處理，因為我們能夠強制的按照時間線將訂單存儲到不同的庫中。但是，有可能我們的電商系統(tǒng)用戶量大，訂單量多，一天就有幾十萬單，可能僅僅半個月，我們的訂單量就會上千萬，再加上訂單的商品數(shù)據(jù)表，如果不分表，訂單表可能就會把系統(tǒng)給拖垮。

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

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

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

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

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

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

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

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

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

如何還原全局視野呢？

還是用我們要查詢第三頁的數(shù)據(jù)來舉例，我們之所以失去了全局視野，是因為我們無法一次性得到所有的數(shù)據(jù)結(jié)果，那么還原全局視野的就是讓我們能夠得到所有的數(shù)據(jù)結(jié)果。因此，我們可以將兩個庫中的從第一頁到第三頁的全部數(shù)據(jù)查詢出來，然后在內(nèi)存中合并后再進行排序，然后就能夠取出正確的第三頁數(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ù)絕對的精準。但是缺點也同樣明顯，當查詢的數(shù)據(jù)量大時，內(nèi)存的消耗就會變多，而且在頁碼增大的時候，查詢效率會急速的下降。當我們有N個數(shù)據(jù)庫，我們需要從查詢X到X Y區(qū)間的數(shù)據(jù)時，那么我們的內(nèi)存中將會需要組合N*(X Y)條數(shù)據(jù)然后排序。

既然全局查詢的有缺點，那我們就來解決這個缺點，但是肯定會有一些其他方面的犧牲。

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

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

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

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

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

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

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

select * from T order by time offset 100 limit 5

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

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

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

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ù)不會發(fā)生變化，但是DB2中的條件被放寬了，因此可能會查詢出更多的數(shù)據(jù)。結(jié)果可能如下：

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

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