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

似乎还是没有人能回答，如果不用 join 的话为何不用 mongo

1. 首先避免或减少 Join 的理由，《高性能 MySQL 》中讲的很清楚了，这个在复杂系统大数据量尤为重要。参考“重构查询方式”章节： https://www.kancloud.cn/ddupl/sql_optimize/1141077
2. 大多数关联场景的 join 是可以拆解成单表查询的，比如 diboot 就是通过注解方式拆解实现关联绑定
3. 少数的跨表字段的搜索查询是没办法避免 join 的，但也可以尽量减少不必要的 join 。比如查询条件有这个字段时再 join 这个表

21 世纪都过了五分之一了啊~~~~还在试图用数据库来解决性能问题？
别忘了 no sql 最初就是为了解决关系型的性能问题而诞生的。以为不用外键就能把性能提升到某种程度的想法，莫非是觉得业务足够简单——简单到了编程语言、业务实现算法、IO 、安全合规要求对性能的影响力小到可以忽略的程度了吗？
DB 压力大，trace 到 root cause 是外键了么，千万别说任何一个系统，数据库的压力大都是因为外键造成的吧？
这种把“具体问题具体分析”抛在脑后的硬性规定，毫无疑问，绝无例外，统统都是半瓢水人云亦云。


比如这位掉书袋的 @myidea 其举例恰恰说明了反向的结论
来来来，画重点了啊，重点，重点，要考的啊！
/*《高性能 MySQL 》中讲的很清楚了，这个在复杂系统大数据量尤为重要。*/
MySQL 不是唯一的关系型数据库，甚至不是关系型代表作——不过这不是重点，重点在于“复杂系统大数据量”。什么样的公司会在所有系统的所有数据表上都达到“复杂系统大数据量”，才会需要用一条题主所说的硬性规定来绝对禁止？
这是典型的：“不够好 = 不好 =不对= 不准= 严禁” 逻辑链啊！

/*大多数关联场景的 join 是可以拆解成单表查询*/
好了，你说的，大多数。你没说不让用，不准用，甚至第三条本质上就是应该用的时候就去用。这是不就结了嘛！题主是反感“不准用”，你这种看似反对，实则的支持的回复，实在是很迷啊！

撸外键的，撸 join 的，撸各种上世纪流传下来的奇技淫巧 sql 优化的，你们随意好了，我现在只想说，我怎么没在 Cosmos DB 上遇到过 join 性能问题呢？嗯，真香~~~

楼上那些动不动就几亿数据的，你们手上真有几亿数据？

真有几亿数据的还不分表分库？怕是分表分库之余还要历史数据归档也要整起来了。因为你不把这些手段使出来，业务根本没法跑，哪怕你禁止 join 也没用，MySQL 单表上千万性能就跌得厉害。

另外，数据库不是给你们无脑存数据的，要想系统稳定高效就得好好学学数据库，无论是关系型数据库还是非关系型数据库。

某些人天天喊着技术技术，结果呢连简单了解下数据库都不乐意。。。别以为会写几句代码就是会编程了，做一个合格的程序员没那么简单。

有一次 join 就会有无数的 join，当然禁止为好

持续关注。。
其实我觉得少用就好，毕竟之前很多业务建表就是以使用 join 来做的。而且 join 性能损失，在表规范前提下，基本可以忽略不计。。
啥都不用了，nosql 不是更好。。。

不让用就换公司，辞职理由：数据库不让用 join 和子查询 [狗头保命]

被 join 坑一次就不会用了

mongo 坏了比较难修理
不 join 确实可以避免性能问题

@xuanbg 老哥怼的好。V2ex 现在的吹 B 程序 员太多 了，都是年轻小粉红。动不动还几亿几亿，十几个列的 mysql 上千万行性能就开始下降了，更不要说万一有大数据组要抽表。

我们做物流系统的时候上了阿里的 DRDS 还要阿里针对 我们改了才好一点，我们是有亿级别的（面单就是亿级别的）

还有微服务，微服务，K8S 。天天吹，然后吹自己纯微服务几百万访问，怎么屌炸天。我就微微一笑

@collery 某楼回贴说自己几亿表，还不分库分表。我就知道 V2EX 已经沦陷到什么地步了。

@594duck 对的，禁止单表数据超过 500 万才是 MySQL 的正确的打开方式，而不是屁用没有的禁止使用 join 。

至于不懂怎么保持单表数据不超过 500 万的小白，我只想说要学会就自己想办法，不要只会无脑往数据库里面怼数据。

觉得不合理。
大多数情况下，join 带来的性能问题，比起他带来的优势是不值得一提的，当能，如果出现了性能问题，在把 join 去了，重写这段代码就行。总比一个 join 也不让用要好，
还有 阿里巴巴 禁用的是超过“”三张表“”的 join .也就是 3 张表以内还是可以用 join 的。并不是一刀切。

@594duck 几亿数据不分库分表有什么问题吗？每个系统的情况不一样，硬件条件也不一样。
之前在电信的时候全是这种几亿数据的表，Oracle，使用一点问题没有。你以为到顶了，结果别人 RAC 做出来，内存就能全部把磁盘数据装下，这是金钱的力量。

这里是知乎吗?人均 BAT?人均千万级?人均亿级流量?Join 一下就成了小白行为?搞技术的有必要弄得这么浮夸吗?都是领福报的人谦虚一点不可以吗？

orm 的关联查询好像都不是 join

@594duck 这尼玛又跟小粉红有啥关系

来，总结一下，结论就是 join 该用就用，超过 3 张表不建议用，用不了不用，跨服务不用，数据库垃圾的不用，中小项目用，大项目可用可不用，喜欢装逼不用，搞不定 SQL 不用，公司有 DBA 不用，觉得关系数据库可以当 KV 用则不用，服务器性能牛逼--用，不用 join 用关系型数据库干嘛的用。。。

是这样吗？

当 PM 一个月改了 114514 次需求的时候...

学习了，哎工作几年了还是菜