日前,某电商用户由于业务发展迅猛,访问量极速增长,导致数据库容量及性能遭遇瓶颈。为降低数据库大小,提升性能,用户决定对架构进行垂直拆分。根据不同的表来进行拆分,对应用程序的影响也更小,拆分规则也会比较简单清晰。
该用户按照会员、商品、订单,将数据垂直拆分至三个数据库,分库后数据分布到不同的数据库实例,以达到降低数据量,增加实例数的扩容目的。然而前途是美好的,道路是曲折的。一旦涉及拆分,就逃不开“原本在同一数据库里的查询,要变成跨两个数据库实例”的查询问题。
单库时,系统中很多列表和详情页所需数据可以简单通过SQL join关联表查询;而拆库后,拆分后的数据可能分布在不同的节点/实例上,不能跨库使用join,此时join带来的问题就很棘手了。
例如:业务中需要展示某个品类商品的售卖订单量,现在订单数据和商品数据分布在两个独立的数据库实例中,业务上要怎么进行关联查询?
用户首先想到的方法是,对现有业务代码进行重构,分别从两个数据库查询数据,然后在业务代码中进行join关联。那么问题来了,如果采用这个解决方案,业务上那么多查询改造起来,拆分难度极大,操作起来过于复杂。跨库join操作又没有非常高效的办法,需要各个分库迭代查询,查询效率也会有一定影响。
是不是光想想就一个头两个大?别担心,关于数据库拆分后的业务改造难题,其实用一条SQL就可轻松搞定。具体解法如下⬇️
解决思路
经沟通,我们发现用户遇到的其实就