牛逼的跨库跨表分页，你扛得住产品的催残吗？

数据展示就会涉及到分页，一般情况下按照create_time排序limit一下就好了。
例如：order by create_time limit m,n

可是数据不安分啊，数据越来越多，你又会把数据分库又分表。分完了，数据存储量可以了。回头我擦分页咋搞嘞。
比如：我们把数据分了两个数据库，比如每页10条数据，你要翻到10页。

基本方案：
每个数据库或表，都按时间排序取10条数据（order by create_time limit 10*10,10），两个数据库或表查询结果排序合并取top10后得到10条数据，你欢喜的觉得简单完成可任务,告诉产品用吧，咱们这数据存储扛扛的。
产品一顿操作（瞎几把点），突然发现越往后翻（例如翻到200页），页面加载需要越久，好像TM卡住了。产品扭头双目盯着你，你脑海飞速旋转order by create limit 200*10,10,一句我cnm差点说出了口。你笑嘻嘻的说，没有人翻200多页吧，一般也就翻个10页8页的，我们可以禁止翻这么多，再说了可以精确查找吗，何必大海捞针。此时产品万古名句，"你这用户体验不好，必须要这样"。你只能继续优化方案。

优化版：
上面的方案其实在翻页码特别大时确实存在很大的问题。怎么优化呢？比如我们能说服产品用户只能跳转10页翻看后面的只能点击下一页，这样我们的方案就来了，那就是每次我们查询回的结果，会有一个时间最大值max_create_time.我们把查询语句改成 where create > max_create_time order by create_time limit 0,10 就OK了。这样每次通过时间就过滤掉了页码之前的数据。
优点：不会出现越翻越慢的情况，每个页码查询速度基本一致，数据精度准确
缺点：10页之后不能跳页查询，只能通过下一页，
这里需要注意下：如果数据分布非常均匀(你一个我一个这样的哈哈)或者允许翻页存在数据精度小误差(例如按时间排序，第二页数据存在一条比第一页数据时间小的情况)，这时候完全可以order by create_time limit 10*10,5 直接合并结果返回，不用做排序处理，而且对于网络占用也较小。
网上还有一些根据最小时间的查询方法，看了一下也是必须保证数据均匀，否则也会出现数据精度误差。