关于跨库分页的思考

在技术社区的大佬们的指引下，我看到一篇关于数据库分页的文章，思路清晰，写的很好。链接如下：
业绩难题，跨库分页的解决方案
遥想自己入行以来，做过许多关于分页的需求和设计，但遇到跨库分页（就是因为业务数据量太大，不得不将数据按照耨中规则零散的分到两个及以上的库来存储）的比较少，毕竟一般的中小型系统，不会涉及到数据库集群分库之类的需求，很多直接都是LMAP架构，很方便，也很节省成本。印象中当年在一个电商网站中碰到过这种数据分库的，当时困扰着项目组的一大问题也是关于实时查询分页。
分页，倘若并非分库的系统，那你可能会说，键值小菜一碟，不费吹灰之力，没错，确实很简单，因为不分库的系统，查询时具备全局视野，那样分页，offset，limit一清二楚，自然很简单，在文章开头的篇幅也是说的很明白，分库分页的根本，就是要获得一个数据库的全局视野。那么你会问了，什么叫做全局视野？
全局视野，也就是相对于分库的前提下，你想啊，本来是一个表的数据（数据量十分大的表），分成了好几个表，而且都是散列分布，比如我有一个A表共有（15条数据），我把A表的数据分存储到B表和C表，如下所示：

这样一来，三个表各有5条数据（这里只是打比方，为了方便假设均匀分配，实际上任何可能性都存在）。原本A库中的第三条数据num3，现在有可能被分到了A，B，C中任何一个表，那么现在，他们之间的原始顺序已经全部打乱，现在谁也不会知道num3是哪一条，num3后三条数据是什么样的，本来单表中十分简单的分页需求变得十分不确定！
所以，链接中的文章指出的就是这个问题！
那我们该怎么办呢，有兴趣的同学可以细细研读链接中的文章。改文章提供了四种方案，有简单臃肿的，也有方案折中的，也有两种兼顾的。尤其是最后一个，二次查询法，这个方案可以说基本解决了这个业绩难题。
不过，话说回来，二次查询法，这个方法的根本还是在于获得数据的全局视野，理论上这种方法只需要获得某一条数据的全局位置，便可以对所有数据进行分页，可以说十分完美。但如此完美的方案，有没有缺陷呢？当然也有，刚刚提到了，二次查询法可以满足任何分页情况，因为它可以曲折的获取到数据的全局视野，这相当于绕了一个大弯子，它也有缺点，它始终都是内存分页，无法摆脱某些效率问题。