V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member Sign In
This topic created in 2562 days ago, the information mentioned may be changed or developed.
有些类似报表的业务需求，通常是十几张表 join 查询，写成一条非常长的 SQL。
从代码层面看，查询即所求，简单但难看。
如果从效能方面看，单条 SQL 是不是比较好。
从代码层面看，查询即所求，简单但难看。
如果从效能方面看，单条 SQL 是不是比较好。
Supplement 1 · Apr 22, 2019
SQL 走索引，有一两张千万级的表，可能有子查询
 |
1
kevinhwang Apr 22, 2019
你能这么问证明你团队无约束。
如果外包请疯狂 join 表然后愉快玩耍。 后续要自己维护的请慎重！！！ |
 |
2
zarvin Apr 22, 2019
我公司后台开发好像就是很多 join，那 sql 语句贼长
|
 |
3
YzSama Apr 22, 2019 via iPhone
我宁愿分开查，增加缓存。。
|
 |
4
passion336699 Apr 22, 2019
 是这种吗, 下面还有很多很多截不完了....  |
 |
5
NoKey Apr 22, 2019
我们这里一般都是分开，然后在编程语言里自行查找组合需要的数据
|
 |
6
adzchao Apr 22, 2019
@passion336699 这不是很正常么 我感觉你这还不是复杂的
|
 |
7
onepunch Apr 22, 2019
小表问题不大。如果表增长无法预期你还是别这么做了
|
 |
8
rockyou12 Apr 22, 2019
统计业务请一定用代码来写，千万别 join N 级。像我们很多 1000 多行，子查询 3、4、5 层的 sql 完全没办法维护……
|
 |
9
Mmiracle110 Apr 22, 2019
join 表多的话，表内数据小还好，表大的话，你试试......
|
 |
10
sjzzz Apr 22, 2019
....建议换一个团队。
|
 |
11
VensonEEE Apr 22, 2019
你们怕啥没见过两万多字的 sql，存储过程。以前某行业应用，报表系统，全 oracle 存储过程，改个逻辑要重写一个星期。 真是佩服 oracle 的性能。
|
 |
12
payboy OP @passion336699 是的，复杂点还有各种子查询。
|
 |
13
Mazexal Apr 22, 2019
第一, 不好做缓存优化
第二, 增加维护成本 第三, 不适合后期做分库分表 第四, 不适合做 sql 查询优化 优势: 一开始写的速度快那么一丢丢 结论你自己想吧 |
 |
14
est Apr 22, 2019
JOIN 没啥不好的。
无脑 JOIN。。。只要 dba 角色那个人能管理得过来也挺好的。 |
 |
16
guyujiezi Apr 22, 2019
join 挺好的，SQL 语句越拼越有意思，还可以为将来系统优化什么的创造 KPI
|
 |
18
DiverRD Apr 22, 2019
join 一时爽，迁移火葬场
|
 |
19
xuanbg Apr 22, 2019
都不会写 sql 吗？几个表 join 就把你们吓坏了？只要单表数据量不上千万级别，join 上 10 来个表数据也能秒出好不好。
话说单表数据量要是上千万级别的，做表结构设计的那个可以解雇了。 |
 |
20
tiedan Apr 22, 2019
我选择 join
|
 |
21
zhchyu999 Apr 22, 2019
后台就怎么爽怎么来，量大 mysql 还是简单查询比较好
|
 |
22
mk0114 Apr 22, 2019
可是有些分页或者过滤一定要联合其他表查询该怎么办呢？
|
 |
23
glacer Apr 22, 2019
统计型 SQL 敢在业务数据库上跑？不怕分分钟拖垮掉？
|
 |
24
lvchao Apr 23, 2019
不用多表 join 对于分页怎么处理
|
 |
25
gosansam Apr 23, 2019
写过一段上午写好 睡个午觉起来就看不懂的 sql 了 join 也就七八个 然后子查询一堆
|
 |
26
jianmo1997 Apr 23, 2019
在我司前一种方式一般都会被 DBA 杀了祭天
|
Select Language