背景

随着数据量的增大，数据库需要进行水平切分，例如通过业务主键id取模，使得数据均匀分布到不同的库中，随之而来的问题就出现跨库如何进行分页查询。

举例

select * from t_user order by time offset 200 limit 100

当在单库单表进行查询的时候，是拥有全局视野的，当进行了水平切分后，就失去了全局视野，数据按照time局部排序之后，不管哪个分库的第3页数据，都不一定是全局排序的第3页数据。

全局视野法

由于失去了全局视野，怎么重新获取全局视野呢，每个库都返回3页数据，所得到的数据在服务层进行内存排序，得到数据全局视野，再取第3页数据，便能够得到想要的全局分页数据。

步骤：

将order by time offset X limit Y，改写成order by time offset 0 limit X+Y
服务层将改写后的SQL语句发往各个分库：即例子中的各取3页数据
假设共分为N个库，服务层将得到N*(X+Y)条数据：即例子中的6页数据
服务层对得到的N*(X+Y)条数据进行内存排序，内存排序后再取偏移量X后的Y条记录，就是全局视野所需的一页数据

方案优点：通过服务层修改SQL语句，扩大数据召回量，能够得到全局视野，业务无损，精准返回所需数据。

方案缺点

每个分库需要返回更多的数据，增大了网络传输量（耗网络）；
除了数据库按照time进行排序，服务层还需要进行二次排序，增大了服务层的计算量（耗CPU）；
最致命的，这个算法随着页码的增大，性能会急剧下降，这是因为SQL改写后每个分库要返回X+Y行数据：返回第3页，offset中的X=200；假如要返回第100页，offset中的X=9900，即每个分库要返回100页数据，数据量和排序量都将大增，性能平方级下降。

业务折中法

全局视野法虽然深分页时候性能较差，但是返回数据准确，有没有性能更优的方案呢，业务需求的折中能够极大的简化技术方案。

业务折中-禁止跳页查询

在数据量很大，翻页数很多的时候，很多产品并不提供“直接跳到指定页面”的功能，而只提供“下一页”的功能，这一个小小的业务折衷，就能极大的降低技术方案的复杂度。

将查询order by time offset 0 limit 100，改写成order by time where time>0 limit 100
上述改写和offset 0 limit 100的效果相同，都是每个分库返回了一页数据
服务层得到2页数据，内存排序，取出前100条数据，作为最终的第一页数据，这个全局的第一页数据，一般来说每个分库都包含一部分数据
点击“下一页”时，需要拉取第二页数据，在第一页数据的基础之上，能够找到第一页数据time的最大值，将查询order by time offset 100 limit 100，改写成order by time where time>$time_max limit 100，这下不是返回2页数据了（“全局视野法，会改写成offset 0 limit 200”），每个分库还是返回一页数据
服务层得到2页数据，内存排序，取出前100条数据，作为最终的第2页数据，这个全局的第2页数据，一般来说也是每个分库都包含一部分数据，如此往复，查询全局视野第100页数据时，不是将查询条件改写为offset 0 limit 9900+100（返回100页数据），而是改写为time>$time_max99 limit 100（仍返回一页数据），以保证数据的传输量和排序的数据量不会随着不断翻页而导致性能下降。

业务折中-允许数据精度损失

全局视野法能够返回业务无损的精确数据，在查询页数较大，例如第100页时，会有性能问题，如果业务上面能够接收返回数据不是那么精准，允许有一些数据偏差，那么可以大大减少技术的实现难度。

例如使用业务主键id取模，理论上在各个分库上的数据分布，统计概率情况是一致的。

利用这一原理，要查询全局100页数据，offset 9900 limit 100改写为offset 4950 limit 50，每个分库偏移4950（一半），获取50条数据（半页），得到的数据集的并集，基本能够认为，是全局数据的offset 9900 limit 100的数据，当然，这一页数据的精度，并不是精准的。

总结：业务折中法需要需求上面进行相应让步，可以搭配上各种搜索条件，能够提高相应精度，也是可以满足多数场景的。