我们知道在分库分表中对于toC业务来说,需要选择用户属性如 user_id 作为分片键,不推荐使用order_id这样的作为分片键。
那问题来了,对于订单表来说,选择了user_id作为分片键以后如何查看订单详情呢?比如下面这样一条SQL:
SELECT * FROM T_ORDER WHERE order_id = 801462878019256325
复制代码
由于查询条件中的order_id不是分片键,所以需要查询所有分片才能得到最终的结果。如果下面有 1000 个分片,那么就需要执行 1000 次这样的 SQL,这时性能就比较差了。
可以通过ShardingSphere-JDBC生成的SQL得知,根据order_id查询会对所有分片进行查询然后通过UNION ALL进行合并。

但是,我们知道 order_id 是主键,应该只有一条返回记录,也就是说,order_id 只存在于一个分片中。这时,可以有以下三种设计:
- 冗余数据法
- 索引表法
- 基因分片法
当然,这三种设计的本质都是通过冗余实现空间换时间的效果,否则就需要扫描所有的分片,当分片数据非常多,效率就会变得极差。
下面我们逐一分析。
设计一:冗余法

这种做法很容易理解,同一份订单数据在插入时保存两份,根据user_id 和 order_id分别做两个分库分表的实现。
通过对表进行冗余,对于 order_id 的查询,只需要

文章讨论了在分库分表场景下,使用user_id作为分片键后如何高效查询order_id。提出了冗余数据法、索引表法和基因法三种解决方案,强调了通过空间换时间的设计来提升查询效率,尤其是基因法能直接通过订单ID定位分片,提高查询性能。
最低0.47元/天 解锁文章
334

被折叠的 条评论
为什么被折叠?



