mysql分庫分表后，跨庫跨表搜索如何排序？
數據庫分庫分表可以說是非常常見的一種應對單表數據量過大的手段了。例如：我們的訂單表，通常情況下，我們會將運單表按照1個月、3個月、6個月以上的維度進行劃分，自然也就會按照時間進行訂單表的水平切分。
這種情況下的分庫分表非常好處理，因為我們能夠強制的按照時間線將訂單存儲到不同的庫中。但是，有可能我們的電商系統用戶量大，訂單量多，一天就有幾十萬單，可能僅僅半個月，我們的訂單量就會上千萬，再加上訂單的商品數據表，如果不分表，訂單表可能就會把系統給拖垮。
那么我們就必須面臨將1個月內的數據也要按照一定的規則進行分庫分表。我們可以將訂單表一分為二，分為了OrderDB1，OrderDB2，按照我們按照訂單號來進行區分。訂單號是單數，我們就放到OrderDB1中，訂單號是雙數，我們就放到OrderDB2中。如此一來，訂單表的數據就被平均的分配到了兩個數據庫的表中了，單表的壓力也就降低了。
而這樣分庫分表以后，我們的訂單表如果需要進行分頁的排序就非常困難了，兩個數據庫中的數據如何進行跨庫的分頁排序查詢呢？
一般我們有三種方法，分別是：全局視野方式、允許精度損失方式、二次查找方式。
先說全局視野方式通常情況下我們要查找第三頁的100條訂單數據，我們會寫一個SQL
select * from T order by time offset 200 limit 100;但是分庫以后，這100條數據可能存在很多種方式。
有可能是平均分布（極端情況）
也有可能是全部來自一個庫（極端情況）
還有可能是散亂分布的（通常情況）
由于情況根據我們的Order By條件有很多的可能，所以我們很難知道第三頁的數據到底從哪個庫的哪個位置開始取數。如果我們需要精準的取到數據，那么就必須重新還原單庫的那種全局視野。
如何還原全局視野呢？
還是用我們要查詢第三頁的數據來舉例，我們之所以失去了全局視野，是因為我們無法一次性得到所有的數據結果，那么還原全局視野的方式就是讓我們能夠得到所有的數據結果。因此，我們可以將兩個庫中的從第一頁到第三頁的全部數據查詢出來，然后在內存中合并后再進行排序，然后就能夠取出正確的第三頁數據了。
自然，我們的sql也就發生了變化，從
select * from T order by time offset 200 limit 100;改為
select * from T order by time offset 0 limit 100+200;使用全局視野方式的好處很明顯，就是數據絕對的精準。但是缺點也同樣明顯，當查詢的數據量大時，內存的消耗就會變多，而且在頁碼增大的時候，查詢效率會急速的下降。當我們有N個數據庫，我們需要從查詢X到X+Y區間的數據時，那么我們的內存中將會需要組合N*(X+Y)條數據然后排序。
既然全局查詢的方式有缺點，那我們就來解決這個缺點，但是肯定會有一些其他方面的犧牲。
允許精度損失方式允許精度損失其實非常的好理解，就是我不去管數據在兩個DB中是如何的分布的，我只是平均的從兩個庫中排序后取出50條數據，然后組合成為100條進行顯示。
當然，這種方式的精度就是根據你排序的條件和數據存儲的方式不同而變化的了。假設我們的數據都是按照時間有序的存儲的，我們的排序也是根據時間來進行排序的，那么我們得到的結果就會比較精準。
但如果我們的數據是隨機插入多個DB的，我們要按照時間進行排序查找，或者我們的數據是按照時間順序插入DB的，但是我們需要根據其他條件進行查找時，數據的精度就會很差。這就看我們對于業務的需要是什么樣的了。
不過，使用這種方式查找，我們就可以不用考慮性能上的問題，查詢的復雜程度很低，只要我們的業務沒有過多的要求，那么使用這種查找方式是最為推薦的。
當然，如果你的業務不允許這樣的情況出現，還需要滿足交互、效率等等各種需求，那么，就我們還可以使用下面這個方式。
二次查詢方式這可以說是解決分庫查詢的究極武器了，能夠保證數據的精準度、查詢的效率、用戶的交互頁面，犧牲的只是小小的性能開銷和一些代碼難度的上升。
方式其實也不難，假設我們要查詢第21頁的數據，每頁5條。這個時候，我們先假設數據是平均分布的，但是我們在每個庫都查詢全量的5條數據。也就是：
select * from T order by time offset 100 limit 5;
這時，我們得到的數據可能是這樣的。
而兩個DB中，最小的時間是1487500001【minTime】，這個時間記錄下來。兩個DB中各自的最大時間也記錄下來，分別是DB1：1487500041【maxTime1】 和 DB2：1487500061【maxTime2】。
這時，我們在使用時間去兩個數據庫中再次進行查詢。
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的數據不會發生變化，但是DB2中的條件被放寬了，因此可能會查詢出更多的數據。結果可能如下：
而兩個結果集合并以后，相當于就獲得了全局視野，也就可以很容易的找出這一頁需要的5條數據了。
當然，我們還可以借助elasticsearch來完成分庫的排序查找，由于elasticsearch引入了緩存機制，能夠讓查詢更快。
