分庫分表下分頁查詢解決方案

不管是隨著業務量的增大、還是隨著使用者數量的增長，在單一表中無法承受大量大資料，導致查詢速度極慢甚至拖垮資料庫。所以分庫分表的策略隨之應用，但是如何在分庫分表的情況下，進行分頁查詢，目前仍是業界難題。

本文記錄了三種情況下，對於分庫分表下的分頁查詢優化方案。

不管是目前的一些資料庫中介軟體例如mycat，還是elasticsearch下的分片查詢，大多都使用了最簡單的策略去實現不同儲存下的全域性有序查詢，即在每次分頁查詢時，查詢所有儲存下相應的條數，彙總排序得到最終要展示的分頁下的數量。

這種策略實現方案簡單、精度高，但是隨著查詢頁數的增長，不管是記憶體的占用還是查詢速度都會極具上公升。因此，如果要採取這種方案，要考慮到對於查詢頁數的限制，防止影響應用的執行。

索引1索引2索引3

索引4索引532

041該策略不會出現當頁數過多時，應用負載過高的情況，但是前提條件為使用者不能跨頁查詢。

在一些後台管理頁面中，分頁查詢是要能支援跨頁查詢的，這樣就無法使用上一種的策略了，但是還可以想辦法做出一些優化。

如果對查詢精度沒有要求的話，可以使用一種簡單的策略，還是拿上面的例子還說明：

查詢需要涉及到五個es的索引，每頁分頁數量是10。

那麼第一頁查詢分別查詢五個索引的0-10條資料再排序返回前十條。

第二頁查詢分別查詢五個索引的10-20條資料再排序返回前十條。

…簡單、效能高，但是問題也是顯而易見的，查詢的精度很低，可能會漏掉許多資料，但是每頁資料無重複。

求得每個索引的查詢條數actualpagesize，用每頁查詢的數量整除索參數量。

即actualpagesize = pagesize / indexsize（向上取整），比如在本例中，pagesize=10,indexsize=5，那麼actualpagesize=2

查詢每個索引下相應頁數的actualpagesize條，

即 limit page * actualpagesize,actualpagesize

彙總所有索引的查詢，排序得到最小的記錄的識別符號minid（如果主鍵是自增就是id，主鍵不是自增就是建立時間cmt_created)，並記錄每個索引各自的最大的記錄的識別符號maxid。注意，minid只有乙個，maxid每個索引都有自己的乙個。

在每個索引中，使用between minid,maxid 查詢相應的結果後彙總排序，得到前十條記錄返回。

ps：為了繼續提高查詢精度，我又做出了改進點，比如，當請求前十頁的資料時，使用策略1，獲取前n頁的所有資料，記憶體排序。請求十頁以後，使用策略3.2。考慮點為前十頁的資料是使用者經常要訪問的，不應該出現資料的丟失和重複，十頁以後的資料基本上不會有人看，資料精度不准頁沒關係。

ps：閾值的設定，不能定的太草率，之前我設定的閾值是10，從第十頁開始，使用不同的策略。也應該考慮一下具體每條資料的大小、記憶體排序時的總空間占用，使用者的併發訪問度等情況。目前閾值的設定為全域性排序時的記憶體占用不能超過5m。

我也不知道什麼樣的業務場景下有該需求啊，但是之前我的部門主管使用過一種策略，可以保證精度不丟失。

噹噹噹噹，就是雙寫

什麼含義呢？就是當新增或者刪除你要查詢的資料列表時，同時向一張新錶中修改所對應的值。

新錶的主要表結構如下，主要作用是，記錄了不同排序規則下，記錄的排序情況。

這樣在查詢時，根據不同的排序條件，查詢不同的排序型別，就得到了乙個全域性排序記錄的id列表，從中擷取你要查詢的頁數量後，再根據id查詢相應的記錄列表。

欄位名稱

字段型別

字段描述

idint

主鍵order_type

tinyint

排序型別

record_id_list

text

有序記錄id列表

限制條件呢有很多，第一，記錄要符合讀多寫少的情況，不然雙寫的效能消耗太大。

第二，排序型別不能過多，我之前的需求是只有一種排序型別的。

第三，記錄id列表中儲存的記錄不能過多，否則就得不償失。