这是一个创建于 3109 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天听人说查询尽量少用连接查询，避免连接大表。 相应的来查询两次来代替连接查询，不知道这个说法是否正确？
 |
1
ballshapesdsd 2017 年 8 月 25 日  1
何出此言。。
|
 |
2
loveCoding 2017 年 8 月 25 日
现在确实比较推荐单表查询 , 把 sql 查询逻辑转移到代码中 , 后期分库分表的话不用改啥代码 .
但是....绝大多数项目到不了分库分表的数据量就挂了... |
 |
3
l00t 2017 年 8 月 25 日
多。Databases are born to join.
|
 |
4
lrh3321 2017 年 8 月 25 日
用的 MongoDB，大多数情况下是查一个 Collection 搞定，多表查询的逻辑在代码里。
|
 |
5
reus 2017 年 8 月 25 日
大错特错
在某些垃圾数据库里虽然正确 但你可以选择不用垃圾啊 |
 |
6
yulitian888 2017 年 8 月 25 日
把 NoSQL 思想放到 SQL 里就是个错误。反之亦然。两者是互补，而不是替代关系
|
|
7
yulitian888 2017 年 8 月 25 日
补充一下，如果对表以行为单位做缓存处理的话，join 确实会很蛋疼。但是这个场景很常见，但是属于程序逻辑，而不是 SQL 该处理的事。这种场景依然可以选择对 join 的结果集进行缓存
|
 |
8
jko123 2017 年 8 月 25 日
hive 用多了，基本都用 join
|
 |
9
MarcoQin 2017 年 8 月 25 日
看慢查询日志，如果 join 让你变慢了那就换
但是如 2 楼所说，一般到不了那种量级项目就挂了 233 |
 |
10
yscg 2017 年 8 月 25 日
join 还是单表，没有优劣之分，知道做一种选择带来的成本和利好更重要。
|
 |
11
akira 2017 年 8 月 25 日
赞同。 很多人的 join 代码写不好，索引做不好。这种情况下，还不如直接让他们不要用
|
 |
12
Charkey 2017 年 8 月 25 日
赞同 2 楼的观点
|
Select Language