业务多表 join，单条 SQL 梭哈一把好还是多次查询在代码整合好

2019 年 4 月 22 日
 payboy
有些类似报表的业务需求，通常是十几张表 join 查询，写成一条非常长的 SQL。
从代码层面看，查询即所求，简单但难看。
如果从效能方面看，单条 SQL 是不是比较好。
6186 次点击
所在节点    Java
26 条回复
kevinhwang
2019 年 4 月 22 日
你能这么问证明你团队无约束。
如果外包请疯狂 join 表然后愉快玩耍。
后续要自己维护的请慎重！！！
zarvin
2019 年 4 月 22 日
我公司后台开发好像就是很多 join，那 sql 语句贼长
YzSama
2019 年 4 月 22 日
我宁愿分开查，增加缓存。。
passion336699
2019 年 4 月 22 日


是这种吗, 下面还有很多很多截不完了....
NoKey
2019 年 4 月 22 日
我们这里一般都是分开，然后在编程语言里自行查找组合需要的数据
adzchao
2019 年 4 月 22 日
@passion336699 这不是很正常么 我感觉你这还不是复杂的
onepunch
2019 年 4 月 22 日
小表问题不大。如果表增长无法预期你还是别这么做了
rockyou12
2019 年 4 月 22 日
统计业务请一定用代码来写，千万别 join N 级。像我们很多 1000 多行，子查询 3、4、5 层的 sql 完全没办法维护……
Mmiracle110
2019 年 4 月 22 日
join 表多的话，表内数据小还好，表大的话，你试试......
sjzzz
2019 年 4 月 22 日
....建议换一个团队。
VensonEEE
2019 年 4 月 22 日
你们怕啥没见过两万多字的 sql，存储过程。以前某行业应用，报表系统，全 oracle 存储过程，改个逻辑要重写一个星期。 真是佩服 oracle 的性能。
payboy
2019 年 4 月 22 日
@passion336699 是的，复杂点还有各种子查询。
Mazexal
2019 年 4 月 22 日
第一, 不好做缓存优化
第二, 增加维护成本
第三, 不适合后期做分库分表
第四, 不适合做 sql 查询优化
优势: 一开始写的速度快那么一丢丢
结论你自己想吧
est
2019 年 4 月 22 日
JOIN 没啥不好的。

无脑 JOIN。。。只要 dba 角色那个人能管理得过来也挺好的。
waising
2019 年 4 月 22 日
@Mazexal #13 关于 sql 优化，平时是没有用 orm 吗？如果是单表的话感觉 orm 的优势也不大了啊
guyujiezi
2019 年 4 月 22 日
join 挺好的，SQL 语句越拼越有意思，还可以为将来系统优化什么的创造 KPI
Removable
2019 年 4 月 22 日
@rockyou12 #8 别说了，我接手的有个模块，之前做的那个沙雕把所有的业务都放到存储过程里了，那维护起来就一言难尽
DiverRD
2019 年 4 月 22 日
join 一时爽，迁移火葬场
xuanbg
2019 年 4 月 22 日
都不会写 sql 吗？几个表 join 就把你们吓坏了？只要单表数据量不上千万级别，join 上 10 来个表数据也能秒出好不好。

话说单表数据量要是上千万级别的，做表结构设计的那个可以解雇了。
tiedan
2019 年 4 月 22 日
我选择 join

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://study.congcong.us/t/557498

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX