单表多次查（业务层）和复杂 sql 查询（有 join、子查询）大家更倾向哪种方案，两者优劣势有哪些

[xipushi]

看情况。有人坚持让我咋用就咋用，都可以。我更喜欢把数据干到一个表，一个 SQL 搞定。

单表多次查，代码里面实现 jion ， 很难懂。数据库服务器压力小。

复杂 SQL ，会导致数据库服务器 cpu I/O 高。 但我觉得你业务代码里面 join 不一定比数据库性能好，只是把 cpu I/O 消耗转移到业务服务器了。

[512357301]

我倾向于复杂 SQL ，见过每秒几百次请求接口的，数据库没疯，后端先疯了，一问是前端不知道要批量查询接口，把点查接口当批查接口用了。
再说了都有 join 和子查询了，你貌似没得选，查询速度肯定慢，只不过是把压力转移到哪里的问题。
如果本地 join 的话，那需要先多次批量查询，把多份数据集存到本地内存，然后内存里做 join ，性能差的话，可以加机器解决，比分库分表简单一些(这也是现在 nosql 数据库常用的方案)。
但是真用到多表 join 了，那还不如查询的时候直接请求大数据的接口呢，他们算力足。

[lsk569937453]

用 join 和子查询就是把压力放到数据库。数据库可是有状态的，不能随意扩容。流量上来了，你就抓瞎了。第一种方案在服务端做，代码复杂，但是无状态的服务扩容简单。

所以互联网很少用 join ，我甚至记得去哪的数据库规范里禁止 join 。

[jackOff]

Join ，单表搞得太复杂你也会懵逼的，而且有时候你的查询数据范围很少，但是你是全部存一张表，那你就要按照条件去全表查询，这个耗时就有点搞事了

[jokechen]

我倾向于单表多次查，前段时间刚刚做了一个账单的业务，数据没有冗余，如果做连表查询，要关联 5 张表一起，每个表的字段名称还不一样，要查的内容的逻辑也不一样，总之联表查询没有 150 行是下不来了。
行数多还没什么，关键的是后续可维护性太差。
在应用端对数据进行整理操作的话，只要抽象、封装做得好，代码维护还是相对容易一些的。

[Bingchunmoli]

看应用层是否是集群（例如我们 k8s 应用层），sql 层是否已经是瓶颈（我们一般买的阿里云的 rds 配置不算高），测试过集群情况下不如应用层合并，单体架构下通常连表效率更高，除非 sql 已经瓶颈，而应用压力较小

[Worldispow]

看数据库性能，mysql 的话最好在把逻辑放到代码里，oracle 的话可以随便折腾

[echo1937]

寻找 “数据库查询性能 vs 数据库网络 IO 开销 vs SQL 可维护性”三者的平衡。

SQL 的可维护性是远低于常见高级语言的，只要不会把数据库干挂，一般选择代码维护最简单的方法，性能后期慢慢优化。

[opengps]

我通常推荐单表多次查，除非有证据表明这个表未来不怎么增长，一定是一个表够用不用拆分优化

[8355]

肯定是第一种，其实并不会慢，而且可以通过代码进行优化，加缓存或者并发查。
如果你可以用 olap 也不会问这个问题了。

[nothingistrue]

两个都是垃圾，比较它俩的优劣是底层互害的行为。当业务/产品和上层架构都是良好的时候，你是不会遇到单表多次查的，复杂 sql 查询可能有但它肯定会被限制在基础设施层（业务层编码人员是看不到也无需理会的）。

[chuck1in]

join 多了你很难优化性能的。

[huijiewei]

JOIN 多了复杂且难以优化，还得要专门的 DBA 。
单表多次就简单暴力多了。灵活性拉满

[YK46PTT]

以前可能用 SQL 一把梭，现在得区分情况，好维护的用 SQL 不好维护的用单表多次查

[adoal]

如果对数据一致性有强要求的话，第一种可能不太靠谱

[silencil]

学到了 以后我也试试单表查。不过单表查询，业务代码中再组合数据感觉业务代码有点乱啊