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

[hackingwu]

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

[d0m2o08]

合理

[hackingwu]

@d0m2o08 合理的原因在哪里？

[simapple]

要是有大表 这样做 也许是合理的

[sun1991]

拿人钱财, 替人消灾. 想开点.

[bokix]

非常合理，现在很多企业开发规范都这么要求的

[wujieyuan]

完全禁止当然不好, 具体情况具体对待, 如果是表过于庞大 join 导致性能降低肯定是不行的, 大部分情况下 join 带来的方便肯定多多,所以需要测试,不能一刀切

[cheng6563]

那也没啥必要用 SQL 了吧

[zjsxwc]

无所谓了，不能 join 就数据库表加冗余字段，
反正数据一致性都是在代码里面保证联动的

[zjsxwc]

@zjsxwc 不过多对多这种，不 join 不行

[reus]

合理个屁，有些垃圾引擎，例如 mysql 5.7 及以前的，计划器低能，才让某些人把不要 join 当真理。
mysql 8，postgresql，sql server，oracle 都能很好地计划和优化 join 。

[cnbattle]

个人看法 ： 合理，理由如下，服务器端的代码优化和 cpu 升级成本低， 数据库优化难度和升级成本高很多

[xpresslink]

合理。
mysql 这种数据库表处于百万级别后使用 join 查询导致性能毁灭级下降。
如果再上升的上千万条要分库分表，就更不能用 join 了。
总而言之，特别是大型分布式系统，数据库最好就当个底层纯数据存储用途，不要加载业务逻辑。

[wysnylc]

合理,join 和子查询性能而且无法跨库跨表
最好连事务都不用,分布式事务也是灾难,在业务中加锁以及用队列处理防止并发即可

[PhpBestRubbish]

我们以前公司技术老大是数据库大牛，他就喜欢整几百上千行的存储过程，不喜欢在项目种做逻辑处理，你要的数据数据库都给你处理好了
所以说什么规范是谁官大就听谁的，没有什么真正的规范

[wo152]

谁权利大，听谁的。

[singerll]

听说阿里的开发规范不允许使用 join，后来我们公司上了阿里的私有云，发现不是不允许，是分库分表根本就没法用，几十个库跨库 join 库和中间件一起炸。。。。。

[huayumo]

这玩意自己搞点测试数据跑一下就知道合理在哪里了，前段时间也在搞这玩意，分拆搞压力确实减轻不少，从一天会出现多次 cpu 跑满，到 cpu 没任何波动，10%左右，同百万数据，再多的没测试过

[ebony0319]

合理，项目大了。并发起来了就知道了。

[huijiewei]

都微服务了为啥要 JOIN ？

假的微服务？

[SmiteChow]

如果公司没有专职 dba，合理，复杂 SQL 审计优化是一门技术，大多数公司不会请 dba，所以把复杂度放置到应用层而不是存储层。

[Mithril]

@PhpBestRubbish 传统以数据库为核心的开发确实是这样的。但是现在数据量上来不会炸的吗？

[Kairyuu]

我们业务里面不让用 统计的功能可以但是也让少用

[dog82]

你们公司只是把数据库当黑盒子使用，没 DBA 吧……
说白了就是守着金山挖煤
充分理解并合理使用各种数据库特性是一个健康的开发团队必须具备的

合理使用数据库特性达到业务目的，比自己 code 强壮得多

[janwarlen]

合理，但是有前提。
前提是表设计合理，如果在辣鸡表设计的基础上这么要求，就相当于让你用竹篮子打水

[nnd]

合理个锤子，领导无能累死士兵。不让用的本质原因是领导自己能力太菜，担心员工能力也菜，用不好，反而拖累数据库。就像现在很多城市禁摩，并不是摩托车污染环境，本质就是管不好，懒政。任何技术都要使用在合适的场景，合理的使用。

阿里的规范是禁止使用存储过程，不是禁止使用 join 。

禁止使用 join，是否能够提高效率，减轻数据库的压力？
答案基本是否定的：
1. 试问各位那个有信心能够写出数据库查询引擎，写出的代码效率比 SQL 引擎效率更高？
2. 不使用 join 和业务实现没有关系，业务实现还不是要从数据库拉取数据，难道这个步骤不增加数据库压力？
3. 完全禁止 join，不如使用 NoSQL 数据库。关系性数据库合理使用就包括使用 join 。
4. 如果感觉业务开发写不好 SQL, 不如增加 DBA HC，做 SQL 审计，效率和质量都比不适用 join 好，并且能节省开发时间。

[monkeyWie]

看业务啊，如果以后数据会很大要分表分库就合理，否则就是搞自己

[chamuyaye]

想问下如果不使用，但是又有分页的要求（数据在各个表中）这种怎么办

[chendy]

除非能把业务逻辑，代码逻辑和数据库设计都优化到不用 join，否则就是在搞自己…

[dog82]

@nnd 不让用存储过程可以理解，因为可移植性太差了

[ranxy]

业务很容易扩展，加机器就行，而数据库不能这么简单的解决。

[AngryPanda]

@huijiewei 微服务和 JOIN 有啥必然联系吗

[smilenceX]

看情况。
这个问题涉及到数据量，索引，查询计划等等各种因素。特别是在多个表联查的时候 join 有时不能正确使用合适的索引导致查询变慢；此外，如果设计不合理，在与其它数据库操作并发时，增加死锁的可能性。
技术之外，如果公司没有专职的 DBA，考虑到开发人员的数据库水平不一致，为避免出现这些问题，硬性做出这种一刀切规定倒也不是不能理解。
确实如你所说，会导致不必要的数据传输，但综合下来，也许是一个可以接受的代价。
为什么会有无效的请求呢？这一点没有理解。

[akira]

小公司随便你搞。

[BBCCBB]

完全禁止不合理.

能少用就少用时合理的..

[asAnotherJack]

@chamuyaye #27 我也想问这个问题

[nnd]

@dog82 不但一致性查，开发写的存储过程也是惨不忍睹。开发写 SQL，就像汽车司机骑自行车；写存储过程是写独轮车，翻车不可避免。当然数据库引擎层面，SQL 引擎效率通常高于 PL/SQL; 我在 O 上面测试过同样的 SQL 、PLSQL，SQL 性能最大好 50 倍

[inwar]

合理,你不一定写得好联表 sql

[ferock]

估计你是 java

各种 Dao，各种 Do，各种单库单对象的权限限制。
当然不能 join，否则还要单独写返回值的对象。

其实完全可以充分利用内存嘛

[dominic0312]

非常合理,,,,,,,,,

[mmdsun]

50%合理

1~2 张表连是可以的。多了不行。

单表可以多线程分多次查，加冗余字段。或者数据聚合导入 es，数据仓库查询。

[liuxey]

1. 看业务类型
2. 看谁职位大
3. 出问题谁背锅

[ychost]

离线计算的话，无所谓的

[howellz]

这还用啥 SQL 啊，SQL 的作用不就是在 db 层面帮你把这些优化做好么?自己在 Client 端写代码去优化整理？把数据库当空气？

[sanggao]

我可以正经告诉你，严格禁止 sql 联表查询，review 发现了你赶紧改去！

[mandex]

具体问题具体对待，有没有性能问题可以测试，为啥要全部禁用呢。
很多地方明明没有性能问题，不让用 JOIN 导致增加了工作量，并没有意义吧。

[changdy]

233 楼上说合理的....让人看不懂, 只能说这个由业务决定和系统架构决定
传统 erp join7~8 张表..再常见不过了...
如果系统的边界划分的非常清晰 , 业务方对查询的要求比较低 当然 join 尽量少....

[newtype0092]

关系型数据库禁止通过关系关联查询？我《数据库系统概论》白学了。。。

[optional]

合理。 互联网 otap 应用不应该用 join.
理由：缓存友好，方便 sharding，方便优化拆分。

[optional]

@newtype0092 其实数据库范式之类的都是面向传统软件的。
大流量的互联网应用都是拿数据库都 kv 用的。

[opengps]

如果你将来数据库达到跨 2 台以上机器，你立刻会改口说很合理！
这种规定说明制定规则的人出发点有分库思路，当然业务是否能达到用的上分库则是另一个话题

[wangsd]

现在公司搞 MES 的，join 十几张表都见过。

[palfortime]

我认为在大部分开发写代码都是复制 /粘贴模式，与实时系统有连接的数据库上都应该禁止 join 。业务做大后，这些语句都已经扩散到整个系统了，大部分领导没有这个魄力来改。

像我司 sql 一把梭，开发时那个爽，也不评估需求是否合理，反正一条 sql 可以处理。db 性能不够？买台核数更大的。
结果，我们的系统被客户采购部署过去时，Oracle 被要求换成 MySQL，核数也有上限。量上来之后，三五天一个炸，都不忍心看客户群里的消息。

[hiboshi]

非常合理 尤其是互联网业务

[bsg1992]

@optional 那你为什么不直接用 KV 用啥关系数据库呢？
你如何判断出一个应用在开发之前是大流量应用呢？

[starcraft]

哈哈哈 刷新认识。第一次见能把懒得学数据库优化 说的这么高大上。你们这帮人不当领导真是可惜了，做个螺丝钉写 crud 真是糟蹋你们。

[yxjn]

有的需求不用 join 根本做不了啊，比如说两个表联合查询，查询条件分布在两个表里。
或者按照题主说的分两步走。如果一个表 in 另一张表的数据，而另一张表查出来的数据又非常多。很容易造成 sql 过长，mysql 甚至执行不了，或者效率严重降低。
既然选择了关系型数据库，就要明白为什么选择它。

[BigBrother1024]

从不关系这类问题，有问题直接向公司提呀

[whoami9894]

那干脆别用关系数据库，不让跨表查询，换 NoSQL 存冗余数据

[optional]

@bsg1992 kv 确实很多啊，但是关系型数据库成熟的索引，读写分离之类的都很方便。只不过用 1+N 查询代替了 jion，但是后台管理，数据分析等 olap 还是大量用 join 的。

[syasuker]

OLTP OLAP 自己看

[love]

不知道楼上这些人哪里听说的 join 伤性能，你分几次查来自己在组装和在数据库端装配好了回来性能没有大的区别

[ragnaroks]

我们公司只有一个限制,一次事务时间不能超过 1ms,其它随意,这种情况下基本不考虑任何数据库逻辑了,都是应用本身去实现

[yulitian888]

先不说规定本身是否正确，但是企图用规定解决性能问题的公司，一定是没有经历过性能问题的公司。
再说这个规定正确吗？嗯，很有可能你们没有一个合格的 DBA，或者，干脆就没有 DBA 吧？！
在这样的公司里，合不合理有意义吗？

[loveyu]

合理，回想 3 次拆表时的痛苦，以那几次的经验，99%的连表都是可以避免或去掉的。

[saberlong]

根据产品定位和场景。能用 join 的话，我更相信没人会故意不用，开发效率上相差太多。不单需要处理更多的计算逻辑，大概率面临性能，资源，开发成本的平衡问题。不是不得已，不会脑抽干这个事情。数据库服务器承载压力总会有上限，不管你是多高端的机器。千万级的表进行大量 join 和复杂的计算，优化到很短就能出结果很常见。不用多，可以尝试下几十几百个同时进行试试会是什么结果。读写分离只能有限改善。只有做分布式，分库分表才有无限扩展的可能。但是这种做法直接导致了很多时候无法 join 。所以很多做法是根据业务场景设计库表，比如将同个用户的数据归到同个分片中，这样只访问该用户数据时可以 join 。无法 join 的时候设计方案处理。放心，总会碰到的

[NotNil1]

今天就被这个问题搞的很烦，数据库查询 3s 超时，但是我一个统计的 sql，要 10s 左右，然后为了不超时，分批拉到内存里统计，10s 的 sql 在内存里要统计好几分钟。

[wangyzj]

这么一刀切
网络 IO 产生的时间不考虑？
而且我不相信会有人用更好的算法去解决数据库中已经固化的算法
过分的 join 或者笛卡尔积是有问题
但是不代表 join 没有优点啊
至于已经分的表，那没办法了，但是不能一刀切

[CoderGeek]

个人觉得一下几点
1.部分人员水平 有些写的 sql 性能底下 索引 优化不懂，减少这种问题禁止 join
2.没有专职 dba 像我们之前生成 sql 都要执行 sql 语句给 dba 审核的
3.分库分表 统计 没存储过程没视图 要么换 nosql 要么用冗余字段宽表减少 join es 一类的统计
4.前人留下脚手架 后续懒惰 成本不替换 比方说 java dao mapper，傻瓜式

[Felldeadbird]

我业务偏向内部系统为主，我很难想象不给用 JOIN，子查询。写财务功能业务代码得写多少逻辑，去组合数据。

[Vegetable]

一朝被蛇咬，十年不 join

[qbmiller]

我们业务上还真没有 Join 除了配置表

[neoblackcap]

@chamuyaye 游标分页，然后上搜索功能。那种传统分页在大数据情况下都是要禁掉的

[neoblackcap]

讲道理，这些人都是很机械地遵循某些规则。阿里的数据多大啊，它的系统想用 join 都用不了，很多表都分库分表了，显然 join 不了了。
另外一个例子就是谷歌，按照谷歌那边大牛的说法，你们在分布式系统里面用 SQL 就是弱者的表现，BigTable 这样的数据库才是正道。
所以不是什么合理不合理，要结合实际情况，因地制宜。我见过从上线到下线都没有超过 10 万数据量的系统。这样的系统我用不用 join 有关系嘛？哪怕不上索引都没有太大关系。
问合不合理之前先看看数据量有多少，系统的客观限制是什么，有没有时效性的限制，是不是分布式系统。仅仅上来就问合不合理，其实你这更多是发泄情绪，寻求认同，我觉得可以理解，但是这对你没有帮助。你应该多点了解你们的系统，多做实验，然后拿数据说话。这样哪怕是领导错了，但是他们不改，你下一份工作你也懂得什么规范是好的，什么规范是画蛇添足。
好比马克斯主义是好，列宁主义是好。但是不本土化，能救中国吗？

[rogwan]

完全禁止 join 矫枉过正了，不超过 2 张表 join 没什么问题。

[Cielsky]

面向领导编程
面向 money 编程
这样你就没有烦恼了

[chihiro2014]

合理，其实说不定请给专业的 DBMS 开发人员更为合理？

[coldear]

禁止 join 可以理解，其实应该使用非关系型数据库

[xy90321]

@love

left join 优化的不好还真的可能会比自己在应用层拼装慢得多

随便几张百万数据级别的表全表扫描一下再来个笛卡尔积谁受的了？

SQL 只是降低了实现的门槛，但不意味着肯定高效，或者说，不意味着在相同付出下一定更高效

[lihongming]

nosql +1

先分析一下你们的真实需求吧，就绝大多数公司而言，90%的请求都是单表甚至单条，用关系型数据库仅仅是为了那 10%的请求。

亚马逊就是意识到了这一点，才开发了 dynamodb，现在这个数据库是 aws 最最主推的产品。

[yukiloh]

顺便问下,jpa 可以做到十张表联查吗
我上次查 3 张表(一对一对多)就报错了

[Mac]

面向大厂编程就是合理的，面向谈不上并发的小应用就是事儿逼

[xuanbg]

不 join 还用个吊毛的性能弱鸡的关系型数据库，直接上 MongoDB 不香吗？

如果业务需要关系模型来支撑的话，那就必须该 join 就 join 。如果查询语句 join 过多导致性能问题，应该反思的是数据结构是否合理，SQL 语句是否能够优化，该有的索引是否建立，而不是一刀切不许 join 。

[kalok]

不明白合理在哪裡，SQL 的精髓就是 join，以及 b-tree 。禁止 Left Join 似乎可以接受，因為會產生大量的 Null 。禁止 Inner Join 就不合理了。如果你們不要 join，那就玩 MongoDB 。還有，善用 explain analyze

[msg7086]

@love 应用服务器跑满了堆机器就行，数据库跑满了咋办？改用读写分离又要改一堆代码还要保证数据一致性，还不如省事让 ORM 把数据装配完得了。

[jss]

当你接触千万级别数据量你就知道了

[hantsy]

@yukiloh JPA 的 JPQL 生成的也是 SQL，有什么问题。

[hantsy]

不要局限 SQL 和 RDBMS，出了这个圈子，一个项目根据场景，还有很多 NoSQL 值得用，Redis，Mongo，Neo4j，ElasticSearch 等。

我是觉得到了 2020 年，现在一个项目还在用 纯 RDBMS 是不思议的。

[stormsuncc]

作为小白，我有个疑问，关系型数据库，多表查询 不使用 join，咋查

[hantsy]

回到主题，如果使用严格的数据关联，没有脏数据，Left Join 和 Inner join，Right join 用在外键关联上，它们有差别吗？

[bsidb]

你们的数据库是面向生产的在线数据库，主要是 OLTP 操作？这种情况不让在数据库端做 join 可以理解，万一 join 耗时太多或者资源太多，把数据库搞挂掉了，其他业务也跟着受影响。
如果是离线分析用的 OLAP，不让用 join 就很奇怪了。

[wushigejiajia01]

@PhpBestRubbish 老公司老项目大多是这样吧？

新项目，像现在的分布式项目还有人这样写？

[wupher]

不合理。

“怕 xx 所以就禁止 xx”其实是一种懒症，不合理的 Join 完全是可以通过每日慢查询识别出来的。

这就像不能因为有小朋友不幸被撞身亡，于是就全面禁止汽车一样。

[john22eclipse]

江湖规矩：微服务=单表查询 ❀☀

[wushigejiajia01]

@AngryPanda 你们微服务不分库的吗？

[ganbuliao]

是你做错了，开发规范上写了不让用 join，那就是不让用 ，不用就好了，哪有那么多的问题？？

[passerbytiny]

不让用在某些情况下合理，“规范”不让用，永远不合理。

[hackingwu]

@msg7086 数据库的从 不能有集群吗

[sanggao]

楼上赞成使用 join 的，都是白白的小白

[hackingwu]

@zjsxwc 如果字段不常变化，可以加冗余。也存在很多字段常变化的，如果冗余，就要多处更新