假設你說的用戶，不是開發人員，是終端用戶，比如saas之類的系統用戶。

如果對于用戶是透明的，意味著每個用戶只需要看到自己的數據，那么比較經濟的處理方式是，把用戶id的哈希值作為分配的條件，這樣能夠保證每個用戶的數據都在同一個分配上。當用戶的請求過來，只需要查詢這個分配，就能像正常的單庫單表一樣的處理分頁方式了。

but，分頁也可以說兩句，簡單的情況就是top，rownum，limit這些常規方式。但是如果數據量非常大的情況下，比如查詢10567頁的100條數據，這就需要先根據where的過濾條件翻過去1056700條記錄，慢成狗。但是我們細想一下，這么多記錄，用戶為什么神特么的需要看這么一百萬記錄。。。其實就是我們自己想多了，壓根不可能有這種需求。怎么辦？要么改需求，搞個熱數據，歸檔數據，把24h的數據存起來，其他的數據歸檔掉，不讓用戶查

要么不提供精確分頁，只讓用戶點擊上一頁，下一頁，每次請求分頁的時候，不帶頁碼，只帶最近的一個id，比如當前頁最后一個數據的id=1056700，點擊了下一頁，就獲取，select * from tablexxx where id>1056700 limit 100，這樣mysql就不用先去從索引數出來一百萬個數據(如果是select * from tablexxx limit 1056700，100)，然后再去拿100個。能快的飛起。

很多時候，從用戶角度思考問題，比技術角度好得多。

如果題主說的一個“用戶”指的是用你這個分片中間件開發人員，他非要不按用戶id來分片，這樣就涉及到多個分片的數據聚合以后再取1056700個記錄后的第100個。笨辦法，沒有：上面這個極端例子，多路查詢，歸并聚合，已經不現實了。。。

好辦法1：用canal之類的同步一個異構的讀從庫，這個庫按用戶維度來分片，或者不分片。

好辦法2：把數據同步到solr或elastic-search里去，做搜索。。。。。最推薦，非常快。

總結

以上是生活随笔為你收集整理的mysql分片库分页查询_准备开发一个数据库分片的中间件，请问下分页查询用什么样的算法效率较高？...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。