（1）分页：
    比如之前的订单场景，假设用户现在要查询自己的订单，同时订单要求要支持分页，该怎么做？其实按照之前我们说的，基本上按照userid先去分库分表的(userid,orderid)索引映射表里查找到你的那些orderid，然后做一个分页就可以了，对分页内的orderid，每个orderid都得去按orderid分库分表的数据里查找完整的订单数据，这就可以搞定分库分表环境下的分页问题了。

    1. 这仅仅是个例子，告诉你的是，如果要在分库分表环境下做分页，最好是保证你的一个主数据粒度(比如userid)是你的分库分表的粒度，可以根据一个业务id路由到一个表找到他的全部数据，这就可以做分页了。但是此时可能就会有人提出一个疑问，如果说现在想要对用户下的订单做分页，但是还同时支持指定的一些查询条件呢？这其实也是很多APP里都支持的，就是对自己的订单查询，有的APP是支持指定一些条件的，甚至是排序规则，比如订单名称模糊搜索，或者是别的条件，比如订单状态。<br />    举个例子，最经典的某个电商APP，在我的订单页面，可以按照订单状态来搜索，分别是全部，待付款，待收货，已完成，已取消，几个状态，同时对订单购买的商品标题进行模糊搜索。那么此时怎么做分页？毕竟你的索引映射表里，只有(userid,orderid)，这是可以在搜索映射表里加入更多的数据，比如(userid,orderid,order_status,product_description)，加上订单所处的状态，以及电商的标题，副标题等文本。然后在对我的订单进行分页的时候，直接就可以根据userid去索引映射表里找到用户的所有订单，然后按照订单状态，商品描述文本模糊匹配去搜索，完了再分页，分页拿到的orderid，再去获取订单需要展示的数据，比如说订单里包含的商品列表，每个商品的缩略图，名称，价格以及所属店铺。
    3. 那如果是针对运营端的分页查询需求呢？数据直接进入ES，通过ESj就可以对多条件进行搜索同时再进行分页，就这样搞定。<br />    当然网上还有说一些所谓的跨库的分页方案，比如说一定要针对多个库和多个表的数据做查询和分页，那这种如果一定要做，基本上只能自己各个库表拉数据到内存，自己内存里做筛选和分页了，或者基于数据库中间件去做，那数据库中间件本质也是干这个的，把各个库表的数据拉到内存做筛选和分页。实际上这种方案效率和性能极差，基本上都是几秒级别的速度。

    （2）总结：
    所以当你觉得似乎必须跨库和表查询和分页的时候，
    建议：
    第一考虑一下是不是可以把查询里按照某个主要的业务id进行分库分表建立一个索引映射表，
    第二是不是可以把这个查询里要的条件都放到索引映射表里
    第三是不是可以通过ES来搞定这个需求。
    尽可能按照上述思路去做分库分表下的分页，而不要做跨库/表的分页查询。

    知识点：映射表也可以做分库分表
    知识点：映射表的数据多了也可以做分表，不管分表规则是什么，目的就是根据业务id能在单表里查到这个用户的所有订单从而方便做分页，避免再内存里做分页。
    知识点：映射表前期可以放一块，如果索引表做分库分表需要满足多个查询条件加分页时，就要用ES了。