关于面试中必问的跨表Join问题

JAVA herman 621浏览
公告:“业余草”微信公众号提供免费CSDN下载服务(只下Java资源),关注业余草微信公众号,添加作者微信:xttblog,发送下载链接帮助你免费下载!
本博客日IP超过1800,PV 2600 左右,急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包,请加博主新的微信号:xttblog,之前的微信号好友位已满,备注:返现
所有面试题(java、前端、数据库、springboot等)一网打尽,请关注文末小程序
视频教程免费领

一般的,像 MySQL 单表数据在 2000W 的时候就要考虑分库分表了。因为,在往上,查询效果下降的就比较明显了。

数据库拆分

然而,分表好分,分起来也很爽。但是分表之后的跨表 Join,或者合并查询就显得很头痛了。今天,我们一起来看看,常见的几个跨表 Join 问题。

1、字典表或全局表的多表备份,避免跨表跨库 Join 查询。

关系型数据库的一大特点就是关联查询。采取分库分表,本来就是分算查询。我先说一种简单的情况,就是字典表。数据本身很少,你对它进行分表吧,数据量太小,根本没必要。不分表吧,关联的表,比如,订单表关联的字典表就需要 Join。如果你分表了,那么就会存在跨表关联问题,而且数据量小,业务复杂度增加。不分表分库,那可能数据就集中在同一个库和表中,Join 起来,大量的查询流量可能集中到某一个库中,反而可能会拖垮。

所以,针对字典表或其他全局表。为了避免跨库 join 查询,我们可以将这类表在其他每个数据库中均保存一份。同时,这类数据通常也很少发生修改(甚至几乎不会),所以也不用太担心“一致性”问题。

2、反范式设计,避免跨库 Join 查询。

这种设计在电商中很常见。比如,我有一个订单表,订单中的每条记录都会关联着卖家的 id 和卖家的 Name。这样做的好处是,很多时候,显示订单中卖家信息时,我不需要去跨表跨库 Join。

3、合理的业务设计,避免跨表跨库查询。

这类问题,最常见的就是我的订单。我要查我所有的订单时候,我希望一张表就搞定了,不需要跨表。也就是说,设计的时候,尽量把同一个用户的订单放到同一张表中。分表的时候,考虑根据用户的 id 分。

4、借助离线计算、流式技术避免跨表跨库查询。

我现在列举一个报表查询的例子。这种情况下,可能就需要跨 N 个表了,而且是没办法避免的。但是我们从设计上,我们要尽量避免 Join 的。如果有多个 join 的,要么是设计不合理,要么是技术选型有误。

报表类的查询实时性要求又不高,所以可以查用离线分析等手段。报表类的系统在传统 BI 时代都是通过 OLAP 数据仓库去实现的,现在则更多是借助离线分析、流式计算等手段实现,而不该向上面描述的那样直接在业务库中执行大量 join 和统计。

以上,4 点,我讲的很简单。其实跨表跨库会带来很多问题。比如,事务问题;如果不跨表很简单,一个注解就可以搞定,但是分表后就比较麻烦了。其他的还有跨节点的 count,order by,group by 以及聚合函数问题。

随着数据量的增加,业务的复杂度也是成比例的增长,原本你一个小时搞定的技术问题,现在如果你没有经验,可能寸步难行!

业余草公众号

最后,欢迎关注我的个人微信公众号:业余草(yyucao)!可加作者微信号1:xmtxtt(5000人已满),微信号2:codedq(5000人已满),微信号3:xttblog(超2800)。备注:“xttblog”,添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注!后续有精彩内容会第一时间发给您!原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系!

本文原文出处:业余草: » 关于面试中必问的跨表Join问题