關於跨庫分頁的思考

在技術社區的大佬們的指引下，我看到一篇關於數據庫分頁的文章，思路清晰，寫的很好。鏈接如下：
業績難題，跨庫分頁的解決方案
遙想自己入行以來，做過許多關於分頁的需求和設計，但遇到跨庫分頁（就是因爲業務數據量太大，不得不將數據按照耨中規則零散的分到兩個及以上的庫來存儲）的比較少，畢竟一般的中小型系統，不會涉及到數據庫集羣分庫之類的需求，很多直接都是LMAP架構，很方便，也很節省成本。印象中當年在一個電商網站中碰到過這種數據分庫的，當時困擾着項目組的一大問題也是關於實時查詢分頁。
分頁，倘若並非分庫的系統，那你可能會說，鍵值小菜一碟，不費吹灰之力，沒錯，確實很簡單，因爲不分庫的系統，查詢時具備全局視野，那樣分頁，offset，limit一清二楚，自然很簡單，在文章開頭的篇幅也是說的很明白，分庫分頁的根本，就是要獲得一個數據庫的全局視野。那麼你會問了，什麼叫做全局視野？
全局視野，也就是相對於分庫的前提下，你想啊，本來是一個表的數據（數據量十分大的表），分成了好幾個表，而且都是散列分佈，比如我有一個A表共有（15條數據），我把A表的數據分存儲到B表和C表，如下所示：

這樣一來，三個表各有5條數據（這裏只是打比方，爲了方便假設均勻分配，實際上任何可能性都存在）。原本A庫中的第三條數據num3，現在有可能被分到了A，B，C中任何一個表，那麼現在，他們之間的原始順序已經全部打亂，現在誰也不會知道num3是哪一條，num3後三條數據是什麼樣的，本來單表中十分簡單的分頁需求變得十分不確定！
所以，鏈接中的文章指出的就是這個問題！
那我們該怎麼辦呢，有興趣的同學可以細細研讀鏈接中的文章。改文章提供了四種方案，有簡單臃腫的，也有方案折中的，也有兩種兼顧的。尤其是最後一個，二次查詢法，這個方案可以說基本解決了這個業績難題。
不過，話說回來，二次查詢法，這個方法的根本還是在於獲得數據的全局視野，理論上這種方法只需要獲得某一條數據的全局位置，便可以對所有數據進行分頁，可以說十分完美。但如此完美的方案，有沒有缺陷呢？當然也有，剛剛提到了，二次查詢法可以滿足任何分頁情況，因爲它可以曲折的獲取到數據的全局視野，這相當於繞了一個大彎子，它也有缺點，它始終都是內存分頁，無法擺脫某些效率問題。