异构索引表，而不是全表复制的原因

    这时你可能会指出，为什么不是将订单的完整数据按照买家ID维度进行次分库保存，这样就只需要进行一次按买家D维度进行数据库的访问就获取到订单的信息?

这是一个好问题，其实淘宝的订单数据就是在异构索引表中全复制的，即订单按照买家ID维度进行分库分表的订单索引表跟以订单ID维度进行分库分表的订单表中的字段完全一样，这样确实避免了多一次的数据库访问。但一般来说，应用可能会按照多个维度创建多个异构索引表，比如为了避免买家查看自己的订单时频繁进行全表扫描，实际中还会以买家ID的维度进行异构索引表的建立，所以采用这样数据全复制的方法会带来大量的数据冗余，从而增加不少数据库存储成本
    另外，在某些场景中，在获取主业务表的列表时，可能需要依赖此业务表所在数据库的子业务表信息，比如订单示例中的主、子订单，因为是以订单ID的维度进行了分库分表，所以该订单相关的子订单、订单明细表都会保存在同一个数据库中，如果我们仅仅是对主订单信息做了数据全复制的异构保存，还是通过一次对这张异构表的数据进行査询获取包含了子订单信息的订单列表时，就会出现跨库join的问题，其对分布式数据层带来的不良影响其实跟之前所说的全表扫描是一样的。所以我们还是建议采用仅仅做异构索引表，而不是数据全复制，同时采用两次SQL请求的方式解决出现全表扫描的问题。