分库分表场景下多维查询解决方案（用户+商户）
在采用分库分表设计时，通过一个PartitionKey根据散列策略将数据分散到不同的库表中，从而有效降低海量数据下C端访问数据库的压力。这种方式可以缓解单一数据库的压力，提升了吞吐量，但同时也带来了新的问题。对于B端商户而言，如何查看这些数据呢？由于数据被散列到不同的库表中，想要查询它们就需要全库表路由查询，这样分库分表将无法带来优势。例如，生成的短链码散列到不同的数据库抵御了海量消费者的访问压力，但在业务层面上，商家无法查询到自己旗下生成的所有短链码。我们对这个问题进行了进一步的分析，寻求解决方案。
方案一：
字段解析配置。定义hash对应的库表策略关系，每次生成库表位时，根据商家的唯一标识进行hash，找到固定的库表位，然后将短链写入该库表中。当商家查询时，同样根据商家的唯一标识进行hash，找到可能在的库表，采用笛卡尔积方式将数据查出，此种方式不触发全库表路由。
| 库 | 表 | 账号hash |
| a,b | c,1 | 1 |
| a | 1 | 2 |
缺点：随不触发全库表的路由，但所涉及库表都会进行查询，给所涉及的库表造成访问压力；
方案二：
Nosql方案。可利用canl-server监听数据库的变动，kafka缓冲，冗余到es中。
缺点：需要实时维护管理缓存数据库的数据。
方案三：
冗余双写方案。拆分买家库和卖家库：1）买家库，按照用户的id来分库分表；2）卖家库，按照卖家的id来分库分表。下订单的时候写两份数据，在买家库和卖家库各写一份。
