我们公司不让开发使用 join 包括 left join,不让用子查询，合理吗？

@hackingwu #173 你说得没错，很多公司写项目是提前考虑读写分离数据延迟的。
但是反过来看，没有提前考虑数据延迟的项目，在遇到数据库瓶颈的时候就要抓瞎了，得返工回去重新做结构。
这种把数据库当 KV 表的做法，可以看成是缓解数据库瓶颈的「另一种」做法。

@dawniii 所以你还是没说为什么呀。
「然后要在内存里组装一个巨大的 sql 出来吗」
所以就让数据库在内存里组装两个巨大的 joined dataset 出来吗？
一个 ID 撑死也就几字节，几万个 ID 也就占用巨大的几十 KB 内存。
几百 GB 的数据表，几十 MB 的索引，放在数据库内存里组装数据集你一点不心疼，几十 KB 反倒是那么心疼？

「如果数据量更大呢」
如果数据量更大，你会发现 MySQL 做 JOIN 或者子查询会更慢……

子查询也好，JOIN 也好，能用上索引和查询缓存的情况只会比单句查询更少。如果是 Oracle 或者 Postges 这些质量比较高的数据库引擎，可能还靠谱点。如果是 MySQL，放在几年前，你查询稍稍写偏一点，或者索引建得让引擎不舒服了，立马 扫·全·表。现在其实也没好到哪里去，但是因为 MySQL 本身速度还挺快的，所以扫全表就扫全表吧，眼不见为净了。

@msg7086 正常来说几百 GB 的数据表，查出来的关联 id 才几万个？我用 join 可不是扫全表的关联关系啊。

@sanggao 牛逼

那就直接用 nosql 数据库吧

@prolic 赞同，脱离实际业务应用场景的讨论都是在杠，
技术方案和规范都不是一成不变的，随着公司发展业务变化在不停地迭代，
没有完美方案，只有当前最优解

@huijiewei 请教一下 这样如果标签数据特别多 开销是不是有点大 而且 In 查询的效率本来就不高把

天天想的是表里有几亿数据怎么办，哪来的数据……

@dawniii
不让用 JOIN 的话，只能这么拆着查。
而且我也说了用 JOIN 应该更快。

重点其实是不用 JOIN 就不这么建表了。

用不用 JOIN 只是不同的观点，并没有什么优劣之分，如果 JOIN 那么不堪，这些个数据库还做这个功能干啥。
如果表是按照关系型数据库范式设计的，在上面做查询当然要用 JOIN 。不用 JOIN 有不用的玩法，从一开始就不一样。
PostgreSQL 在 2008 年加的 hstore，2012 年加的 JSON，都是反范式的功能。在反范式的表上不用 JOIN 来查询就很正常了。

在互联网项目中，程序的执行效率并不是摆在第一位的，摆在第一位的应该是程序的水平扩展性和可维护性。

该不该用 JOIN，当然不能一刀切。但是，作为新人，你觉得你比同事更加了解你们的项目吗？

引用《高性能 MySQL 》——6.3.3-分解关联查询，总结得很全面：

很多高性能的应用都会对关联查询进行分解，有如下的优势：
1 、让缓存效率更高。如果某张表很少变化，那么基于该表的查询就可以重复利用查询缓存结果。
2 、将查询分解后，执行单个查询可以减少锁的竞争。
3 、在应用层做关联，可以更容易对数据库进行拆分，更容易做到高性能和可扩展。
4 、查询本身效率也可能会有所提升。例如 IN()代替关联查询，可能比随机的关联更高效。
5 、减少冗余记录得查询。
6 、更进一步，这样做相当于在应用中实现了哈希关联，而不是使用 MySQL 得嵌套循环关联。某些场景哈希关联得效率要高很多。

不过补充下，本书虽然很好，但是是基于 MySQL 5.5 的，现在 MySQL 已经发展了不少，对于 JOIN 的优化也多了很多。

@dawniii 几百 GB 的数据表，做过滤查询的时候只查出一部分不是很正常吗？
如果你用 JOIN，能保证充分利用索引做高速连接，我觉得是没有问题的。
不过这里主要讨论的是不做连接的时候性能会受到多大影响的问题。
实际开发环境中有很多查询，在使用 JOIN 时无法充分利用索引，或者至少 MySQL 会比较笨不去用索引，这种时候做简单查询然后手动去处理，可能会比依赖数据库内部查询优化速度更快一些。毕竟查询优化并不一定能洞悉你最终的意图，并不一定能给出最佳的查询计划。

楼上#187 里也举了很多相关的例子，提到的这些其实也就是我们上面提到的，服务器更容易扩展，更容易利用查询缓存，减少锁等等。我个人并不反对使用简单的 JOIN 查询，但是对于应用层简单而数据库层复杂的查询，我是绝对会放在应用层做的。

@goodboy95 我们公司搜索差不多 一个订单搜索十几个搜索项 基本都是模糊搜索 而且还是从不同的表中检索

@msg7086 整个帖子看下来，感觉就是三个原因不用 join 。

1. 开发人员水平参差不齐
2. mysql“垃圾”
3. 业务扩展性

都这么纠结了，是不是直接用 nosql 会更好。

用了 nosql 你就要开始纠结数据为啥不对了

一圈回覆看下來，有的老哥不知道哪裡來的想法。如果分表但不分 DB，是真的用 join 比較快。這一點在新版的 MySQL 或者 PostgreSQL 都是做過實驗的。表放在不同的 DB 上的話，就有小心考慮了。而且 many to many 的關係，一般也是 join 的效率高，代碼也簡潔。如果喜歡一個表玩到底，真心推薦 MongoDB

主键 join 最多 2 张表，多了不推荐

在一些人眼中 程序员就该 熟悉各种算法、数据结构
啥？ 不会也好意思自称程序员
大公司屈指可数 而大部分创业公司都是 CRUD BOY 足矣
你觉着不让用 join 太 low
你想想你们公司的开发人员算法平均水平溜吗

没公主命 就别有公主病
禁用 join 是偷懒 但你想想公司有几个 dba
或者说你希望担起 dba 的责任 那么领导对你有这个信心？

其实就算 join 写的垃圾 数据量没大到一定程度也不会很卡
说白点 要么忍 要么狠 要么滚
你牛的话 让下属全部写存储过程又怎样

@dawniii 更换技术栈一样有学习成本和招人成本。NoSQL 也不是就没缺点的。对很多公司来说，这种折中的操作更方便。

像我们写 Rails 的其实只需要操作上层模型就行了，下层 ORM 会自动选用 join 或者单句查询，你改成 NoSQL 的话很多现成的工具都没法用，又要重新做技术储备，重新找类库，甚至重新写组件，我觉得没有太大的优势。

不在数据库写 join 那确实需要用到多表 join 的地方怎么办呢，自己把数据查回来然后在代码里 join ？

公司规范 是由公司技术负责人提出的，肯定是会统盘考虑公司的业务，技术人员水准等情况，做出的一个最优解。

这个时候 ，做为一个公司员工，在没有了解完整信息前，要做的，就是遵循公司规范就好。

唯技术论的形而上学主义要不得。

关系型数据库任何关系都是有代价的，自己看着用呗，反正我们不准用。业务的易变特性决定了代码审计比 SQL 审计手段多且更有效