再复习：分库分表常见问题整理

一.非分片键如何查询？

方法1：冗余法

设置两个分片键，分别做两个分库分表的实现

缺点：数据冗余太大

方法2：索引表法

索引表法是对第一种冗余法的改进，由于第一种方案冗余的数据量太大，所以索引表方案中只创建一个包含分片键和查询条件的索引表，在插入订单时再插入一条数据到索引表中。

方法3：基因法（最重要）

基因法的核心，就是把分片键的信息插入到查询条件中

假如我们分了十六个表，那哈希分表其实就是哈希值除以16的余数。也就是哈希值的最后四个比特位决定了分到哪个分片。

那么我们在构建查询条件时，只需要在最后四个比特位携带上分片键的最后四位就好了。

具体例子：假如有一个用户优惠券表，主要包含三个重要id：主键id，用户id，店铺id，用户id是分片键。此时我们想要使用主键id进行查询，那么在构建主键id时，设置最后四位为用户id的最后四位。此时不管是用主键id查询还是用户id查询，最后对16取模，结果都会是同一个分片。

问题：如果要用店铺id查，该怎么办

可以使用冗余法，分别按照店铺id和用户id使用两种分库分表方案

二.跨数据库连表查询

1.当使用shardingSpare进行连表查询时：

如果两个表的分片键都是on的条件的话，则会直接去对应库中查询；否则就会进行广播查询

2.设置数据冗余，避免连表查询

3.在业务层进行组装，分别进行查询

三.分库分表扩容

1.停机扩容

2.不停机扩容

可以使用ShardingSphere-Scaling，首先会创建一套新的订单数据库，将历史数据按照新的路由规则分配到新的数据库中，并在旧数据库的操作中开启双写，同时写入到两个数据库。然后用新的读写服务逐步替代旧服务，同步进行数据不一致校验，最后完成全面切流。

3.分片算法选择

可以使用一致性哈希算法，可以保证最少数量的数据迁移。一致性哈希算法会选择顺时针方向距离最近的节点作为分片节点，所以每次最多只会迁移一个数据库的数据