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