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

查询

SQL

join

劣势

16 条回复 • 2023-08-25 10:34:35 +08:00

1

xipushi

2023-08-24 22:41:50 +08:00 via Android

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

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

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

2

512357301

2023-08-24 23:42:14 +08:00 via Android

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

3

lsk569937453

2023-08-24 23:53:53 +08:00 via Android

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

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

4

jackOff

2023-08-24 23:55:57 +08:00 via Android

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

5

jokechen

2023-08-25 00:01:13 +08:00

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