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

@dawniii 这么跟你说吧，你可以用关系型数据库去存小字段数据，大字段数据推荐放 nosql 中，比如 mongodb 。只是拿 nosql 作为存储工具。当然，现在像 mysql 已经非常给力了，8.0 版本后性能有了质的飞跃，你数据量小，用 mysql 随便怎么玩都行

@dawniii 我指的数据量小是在几十亿量级的，用 mysql 抗的住，即使不用分库分表，前提是对表设计要求非常严格，比说楼主提的，绝不允许 join 查询

不用 join 导致的问题就是不符合数据库三范式。大表 join 确实查询会很慢（仅用过 mysql ），用程序来处理数据库压力是减轻了，是否有测过处理时 web 服务器的消耗。不 join 的前提是原本多张表的数据放同一张，程序也不需要查多张再处理。

微服务架构本来就不应该去关联不属于你的服务的表，应该用接口的方式去通信，禁止 join 的做法没有错，前天刚看到我司四个 join 的语句，explain 出来连续四五个 nested loop，如果你能为你写的 join 语句担责，愿意赔钱，那没问题，不然就老老实实遵守公司的规则。如果你觉得你司的数据量就这么小，以后也涨不了多少，那你大可以跟你老板去说，辞职吧。

@encro 我觉得重点不是 sql 不敢用这个问题，是很多开发其实用不好复杂的 sql，而且当你的业务数据达到几十亿，上百亿后，很难在 sql 上去做优化，目前就 mysql 而言，只有分库分表一条路。但是分库分表带来的成本是很高的，如果项目初期就野蛮放纵，让开发瞎写 sql，当你想做分库分表的时候就知道有多痛苦了。所以基本上，都会有类似楼主公司的一些限制，为的就是后面数据量级上来好做优化

@dawniii 你这个简单的不能再简单了。小系统的归类统计不值得上专门的统计系统，用用 JOIN 也就罢了，你这种简单的 3 连有什么必要用 JOIN ？ 分拆成 3 个 SQL 不就完事了

@magicnian 你说的部分数据放到 mongo，如果查询字段同时有 mongo 和 mysql 的字段岂不是炸裂。我倒是觉得数据量大了，把查询的关键字段都放到 es 或者 nosql，然后用主键去 mysql 查详情就好。

多表查询不建议用 join,如果查询条件分布在多表中，用视图比较好

@huijiewei 不用 join 我是实现不了，请教下这个怎么拆成 3 个 sql 还能满足需求。

@lichao 我只是想知道，楼主这个想法是哪里来的，不是我的想法。

@huijiewei 简单的 3 连可还行，你拆分出来的 3 个 sql 不会把整张表读出来了吧，不然的话我是想不到怎么在有多表搜索条件的情况下保证分页功能正常的。

一杆子打死的- -

@sanggao 请解释原因

说真的，不让用 join 就算了，楼上还有人说一块把事务禁掉的，这还用个 x 的 mysql ？光论存取的话 mongodb 那是真比 mysql 快。
说真的，有些情况下需求方真提个蛋疼的需求，完全可以把整个代码规范搞死。我现在做一个系统，存储人员的姓名和工号还有别的玩意，结果需求方要求可以输入员工名字 /工号的一部分（有可能是中间一部分）去搜索，这种操作别说 mysql 了，es 都是让人尽量不用的（虽然 es 的 wildcard 搜索确实比 mysql 快不少），但我能怎么办？一看人员数量，也就万把人吧，一年也不会增长 1000 个，最后也只能做了。

@dawniii
@goodboy95

你们是多小白啊，这么简单的都不会
SELECT id FROM tag WHERE name = XXX 取出 tag id,
SELECT id FROM user WHERE name = XXX 取出 user id

SELECT * FROM article WHERE tag_id IN(tag_ids)
SELECT * FROM article WHERE user_id IN(user_ids)

有什么难点？你告诉我

对业务自信，这样做完全没得问题，开发也很清晰，维护别人代码也容易，另外阿里开发手册是不是也不推荐用任何 join ？ 反正我们已经很久不用了

@nnd #25L 我猜楼主的技术架构中间层来进行扩展，数据库只是作为存储，不处理任何逻辑，将逻辑放在中间层，很方便跨库查询，分表分库？ 估计有一套自己的事务控制，和自己的缓存控制。 所以才禁止使用 join 。

@huijiewei 你的 article 表可以 in 查询 tag_id? 这么神奇的吗？手动狗头

如果用了 join 对缓存的命中这一块，以及分库分表这一块非常难处理。 不用 join 是对缓存命中，和分库分表的妥协。

不能只看当前，看看未来。相比于不用 join 带来的开发效率损失，业务量上去以后进行服务拆分带来的工作量才是大成本。
给未来留后路，我认为不是什么问题，甚至很明智。
但如果这个业务本来也不是那种今后业务会很大的项目，比如某某内部管理系统，那有这个规定，纯属有问题