为什么强烈建议你不要做联表查询?

Posted Java知音_

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了为什么强烈建议你不要做联表查询?相关的知识,希望对你有一定的参考价值。

前言

一直想要聊一聊关于开发中更建议使用单表查询+代码层组装 or 联表查询 的问题,在开发中每个同学的开发中有各自的习惯,笔者在公司也和一些同事关于这方面有一些探讨。

关于本文,更像是一些个人的看法,想到什么说什么,一定有不同的意见,欢迎大家留言,一起讨论。

对比

在实际开发中,我们不可避免的要关联几张数据表来合成最终的展示数据,如:

select * from tag
join tag_post on tag_post.tag_id=tag.id
join post on tag_post.post_id=post.id
where tag.tag='mysql';

同样的,我们可以用以下查询来代替:

select * from tag where tag='mysql';

select * from tag_post where tag_id=1234;

select * from post where id in(123,456,567,9989,8909);

看似后者查询步骤更多了,原本一个方法查询就能出结果,现在直接变成三个。但是这样做的好处是:

1、单表查询更利于后续的维护。

在实际开发场景中,在代码初步开发阶段(如果摊上一个不太靠谱的产品),业务发生变动,某张表的结构发生变动,很可能整个join查询都变得不可用,复杂的关联查询,在修改时,基本等于推倒重来。

但是如果我们使用了单表查询,拆成上诉例子中的三个步骤,我们可能只需要修改其中的一个步骤即可,比较利于维护。

2、代码可复用性高

这个不用多说,join联表的SQL,基本不太可能被复用,但是拆分后的单表查询,比如上面例子中,我查询出tab数据,任何地方组装需要tab数据,我都不需要再次做相关查询,直接使用。

3、效率问题

join联表查询,小表驱动大表,通过索引字段进行关联。如果表记录比较少的话,效率还是OK的,有时效率超过单表查询。但是如果数据量上去,多表查询是笛卡尔乘积方式,需要检索的数据是几何倍上升的。另外多表查询索引设计上也考验开发者的功底,索引设计不合理,大数据量下的多表查询,很可能把数据库拖垮。

相比而言,拆分成单表查询+代码上组装,业务逻辑更清晰,优化更方便,单个表的索引设计上也更简单。用多几行代码,多几次数据库查询换取这些优点,还是很值得的。

4、减少冗余字段的查询

在很多业务中,我们可能对某条记录只需要查询一次,此时如何使用关联查询,则不可避免的需要重复地访问一部分数据,从而可能会加剧网络和内存的消耗。

5、缓存利用率更高

比如上面查询中的tag是不常变动的数据,缓存下来,每次查询就可以跳过第一条查询语句。而关联查询,任何一张表的数据变动都会引起缓存结果的失效,缓存利用率不会很高。

6、其他

数据库资源比较宝贵,很多系统的瓶颈就在数据库上,很多复杂的逻辑我们在Service做,不在数据库处理会更好。

在后续数据量上去,需要分库分表时,Join查询更不利于分库分表,目前MySQL的分布式中间件,跨库join表现不良。

单表查询+代码上组装相当于解耦,现在开发中,我们常常使用各种ORM框架,不知道你的联查orm给你搞成了什么样,你是很难直接优化。

以上理由,强烈推荐在今后的开发中,尽可能的使用单表查询+代码上组装的方式。使用Stream lambda + mybatis plus + lombok, 酸爽!

单表 VS 联表

基本就这些了,你的看法呢?

END

推荐好文

强大,10k+点赞的 SpringBoot 后台管理系统竟然出了详细教程!

分享一套基于SpringBoot和Vue的企业级中后台开源项目,代码很规范!
能挣钱的,开源 SpringBoot 商城系统,功能超全,超漂亮!


以上是关于为什么强烈建议你不要做联表查询?的主要内容,如果未能解决你的问题,请参考以下文章

了解MySQL联表查询中的驱动表,优化查询,以小表驱动大表

代码变量拆分大SQL

从个人发展的角度看,为什么不建议你考虑QA岗位?

强烈推荐可能是最适合你的 Java 学习路线和方法!建议收藏

mssql联表查询

django框架七