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

[hackingwu]

我们公司规范不让开发使用 join 包括 left join,也不让用子查询，原因是为了减轻 DB 的压力，这样就导致我们一个多表联合查询的业务就要拆分多条语句，导致无效的请求和数据传输。我们业务是微服务架构。 我觉得是很不合理的。减轻了 DB parse 的压力，却带来了处理请求和数据传输的压力。 大家觉得呢？是我错了吗？

[Narcissu5]

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

[myidea]

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

[yulitian888]

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


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

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

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

[xuanbg]

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

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

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

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

[lux182]

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

[kn007]

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

[xiebruce]

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

[memeda]

被 join 坑一次就不会用了

[xcstream]

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

[594duck]

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

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

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

[594duck]

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

[xuanbg]

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

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

[egfegdfr]

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

[sonice]

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

[dk7952638]

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

[cooooler]

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

[cooooler]

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

[Hanggi]

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

是这样吗？

[JerryCha]

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

[matenshi]

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

[594duck]

@sonice 你也说了你是 Oracle，人家是 Mysql 你让 Mysql 单表千万级数据，不用多，10 个列好了，直接废了。

[594duck]

@Hanggi 老哥问的好，不用 Join 还用什么关系数据库。肯定是他们微服务拆的太散了，导致随便 Join 一下好多表

[Judoon]

https://www.oschina.net/question/4518288_2316959

[Judoon]

oschina 上的帖子看起来这也是你发的？为了引战么，一个论坛不够，多发几个？或者为了找认同感

[hackingwu]

@Judoon 。。。。不知道是谁复制黏贴发的，我已经冲大家的回复里找到自己的答案了

[pythonee]

记得几年前，去 O 和 KV 数据库流行的时候，互联网很多这些实践
需要根据业务评估，随着不同的业务阶段，再具体做选择吧

[594duck]

@sonice 又来了，开始春秋笔法啦，我们在讲的是 MYSQL 单表几亿。ORACLE，几亿不是很正常。RAC 我接触过天玑科技，国产的。

昨天还是前天还有个小朋友和我说 1G 内存跑了 1 万连接并发的 HTTP 网站。 我说吹牛逼，他说我水平不好，二次元斗图乱发，我和他推理半天，他发我一份 NET 优化表，说是优化的。我说 1G 内存再优化也优化不出 C10K 问题。

最后他给出一个域名，我一看 cloudflare，再一看页面，静态就三个字。我问他你这 CDN 缓存 和你 1G 内存，和你的 NET 优化表有什么关联么？和你的 C10K 有什么关联么？

又是几个表情

这就是春秋笔法。

[594duck]

@sonice 噢，我回复过你啦。抱歉，我给你点个 LIKE 补偿

[yogapants]

@sdwgyzyxy 大佬想请教一下分库分表之后如果使用了数据库中间件的话，各种聚合统计、连表操作是不是最好不要用了。因为既然分库分表了说明应该数据量庞大已经完全拆成微服务了，相应的数据库服务器也应该独立开来。再以传统的方式的话意义不大。

[sdwgyzyxy]

@yogapants 哈哈，第一次被人称为大佬，其实我就是一个菜鸟，并没有什么经验，就是根据我们项目发的一条感悟，你看看就行了，我经历过拆分 join 的痛，开发人员无视业务表隔离，比如 join 用户表、订单表、流水表，明显的数据表名称前缀都不一样就不要强行 join 了。

[ZX16815]

数据传输一般走内网，传输压力可以忽略不计。
如果能保证，被 join 的表，将来永远不会被分库分表的话，可以 join 。但这个谁也保证不了