我们公司规范不让开发使用 join 包括 left join,也不让用子查询，原因是为了减轻 DB 的压力，这样就导致我们一个多表联合查询的业务就要拆分多条语句，导致无效的请求和数据传输。我们业务是微服务架构。 我觉得是很不合理的。减轻了 DB parse 的压力，却带来了处理请求和数据传输的压力。 大家觉得呢？是我错了吗？
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 2202 days ago, the information mentioned may be changed or developed.
 |
201
Narcissu5 Jun 4, 2020
似乎还是没有人能回答，如果不用 join 的话为何不用 mongo
|
 |
202
myidea Jun 4, 2020
1. 首先避免或减少 Join 的理由，《高性能 MySQL 》中讲的很清楚了，这个在复杂系统大数据量尤为重要。参考“重构查询方式”章节： https://www.kancloud.cn/ddupl/sql_optimize/1141077
2. 大多数关联场景的 join 是可以拆解成单表查询的，比如 diboot 就是通过注解方式拆解实现关联绑定 3. 少数的跨表字段的搜索查询是没办法避免 join 的，但也可以尽量减少不必要的 join 。比如查询条件有这个字段时再 join 这个表 |
 |
203
yulitian888 Jun 4, 2020  3
21 世纪都过了五分之一了啊~~~~还在试图用数据库来解决性能问题？
别忘了 no sql 最初就是为了解决关系型的性能问题而诞生的。以为不用外键就能把性能提升到某种程度的想法，莫非是觉得业务足够简单——简单到了编程语言、业务实现算法、IO 、安全合规要求对性能的影响力小到可以忽略的程度了吗？ DB 压力大，trace 到 root cause 是外键了么，千万别说任何一个系统，数据库的压力大都是因为外键造成的吧？ 这种把“具体问题具体分析”抛在脑后的硬性规定，毫无疑问，绝无例外，统统都是半瓢水人云亦云。 比如这位掉书袋的 @myidea 其举例恰恰说明了反向的结论 来来来，画重点了啊，重点，重点，要考的啊！ /*《高性能 MySQL 》中讲的很清楚了，这个在复杂系统大数据量尤为重要。*/ MySQL 不是唯一的关系型数据库，甚至不是关系型代表作——不过这不是重点，重点在于“复杂系统大数据量”。什么样的公司会在所有系统的所有数据表上都达到“复杂系统大数据量”，才会需要用一条题主所说的硬性规定来绝对禁止？ 这是典型的：“不够好 = 不好 =不对= 不准= 严禁” 逻辑链啊！ /*大多数关联场景的 join 是可以拆解成单表查询*/ 好了，你说的，大多数。你没说不让用，不准用，甚至第三条本质上就是应该用的时候就去用。这是不就结了嘛！题主是反感“不准用”，你这种看似反对，实则的支持的回复，实在是很迷啊！ 撸外键的，撸 join 的，撸各种上世纪流传下来的奇技淫巧 sql 优化的，你们随意好了，我现在只想说，我怎么没在 Cosmos DB 上遇到过 join 性能问题呢？嗯，真香~~~ |
 |
204
xuanbg Jun 4, 2020 1
楼上那些动不动就几亿数据的，你们手上真有几亿数据？
真有几亿数据的还不分表分库？怕是分表分库之余还要历史数据归档也要整起来了。因为你不把这些手段使出来，业务根本没法跑，哪怕你禁止 join 也没用，MySQL 单表上千万性能就跌得厉害。 另外，数据库不是给你们无脑存数据的，要想系统稳定高效就得好好学学数据库，无论是关系型数据库还是非关系型数据库。 某些人天天喊着技术技术，结果呢连简单了解下数据库都不乐意。。。别以为会写几句代码就是会编程了，做一个合格的程序员没那么简单。 |
 |
205
lux182 Jun 4, 2020
有一次 join 就会有无数的 join，当然禁止为好
|
 |
206
kn007 Jun 5, 2020
持续关注。。
其实我觉得少用就好，毕竟之前很多业务建表就是以使用 join 来做的。而且 join 性能损失，在表规范前提下，基本可以忽略不计。。 啥都不用了，nosql 不是更好。。。 |
 |
207
xiebruce Jun 5, 2020
不让用就换公司，辞职理由：数据库不让用 join 和子查询 [狗头保命]
|
 |
208
memeda Jun 5, 2020
被 join 坑一次就不会用了
|
 |
209
xcstream Jun 5, 2020
mongo 坏了比较难修理
不 join 确实可以避免性能问题 |
 |
210
594duck Jun 5, 2020 1
@xuanbg 老哥怼的好。V2ex 现在的吹 B 程序 员太多 了，都是年轻小粉红。动不动还几亿几亿，十几个列的 mysql 上千万行性能就开始下降了，更不要说万一有大数据组要抽表。
我们做物流系统的时候上了阿里的 DRDS 还要阿里针对 我们改了才好一点，我们是有亿级别的（面单就是亿级别的） 还有微服务，微服务，K8S 。天天吹，然后吹自己纯微服务几百万访问，怎么屌炸天。我就微微一笑 |
|
212
xuanbg Jun 5, 2020
@594duck 对的，禁止单表数据超过 500 万才是 MySQL 的正确的打开方式，而不是屁用没有的禁止使用 join 。
至于不懂怎么保持单表数据不超过 500 万的小白，我只想说要学会就自己想办法，不要只会无脑往数据库里面怼数据。 |
 |
213
egfegdfr Jun 5, 2020
觉得不合理。
大多数情况下，join 带来的性能问题，比起他带来的优势是不值得一提的，当能，如果出现了性能问题，在把 join 去了，重写这段代码就行。总比一个 join 也不让用要好， 还有 阿里巴巴 禁用的是超过“”三张表“”的 join .也就是 3 张表以内还是可以用 join 的。并不是一刀切。 |
 |
214
sonice Jun 5, 2020 1
@594duck 几亿数据不分库分表有什么问题吗？每个系统的情况不一样，硬件条件也不一样。
之前在电信的时候全是这种几亿数据的表，Oracle，使用一点问题没有。你以为到顶了，结果别人 RAC 做出来，内存就能全部把磁盘数据装下，这是金钱的力量。 |
 |
215
dk7952638 Jun 5, 2020 1
这里是知乎吗?人均 BAT?人均千万级?人均亿级流量?Join 一下就成了小白行为?搞技术的有必要弄得这么浮夸吗?都是领福报的人谦虚一点不可以吗？
|
 |
216
cooooler Jun 5, 2020
orm 的关联查询好像都不是 join
|
 |
218
Hanggi Jun 5, 2020
来，总结一下，结论就是 join 该用就用，超过 3 张表不建议用，用不了不用，跨服务不用，数据库垃圾的不用，中小项目用，大项目可用可不用，喜欢装逼不用，搞不定 SQL 不用，公司有 DBA 不用，觉得关系数据库可以当 KV 用则不用，服务器性能牛逼--用，不用 join 用关系型数据库干嘛的用。。。
是这样吗？ |
 |
219
JerryCha Jun 5, 2020
当 PM 一个月改了 114514 次需求的时候...
|
 |
220
matenshi Jun 5, 2020
学习了，哎工作几年了还是菜
|
 |
223
Judoon Jun 6, 2020
|
|
224
Judoon Jun 6, 2020
oschina 上的帖子看起来这也是你发的？为了引战么，一个论坛不够，多发几个？或者为了找认同感
|
 |
226
pythonee Jun 19, 2020
记得几年前，去 O 和 KV 数据库流行的时候，互联网很多这些实践
需要根据业务评估，随着不同的业务阶段，再具体做选择吧 |
|
227
594duck Jul 9, 2020
@sonice 又来了，开始春秋笔法啦，我们在讲的是 MYSQL 单表几亿。ORACLE，几亿不是很正常。RAC 我接触过天玑科技，国产的。
昨天还是前天还有个小朋友和我说 1G 内存跑了 1 万连接并发的 HTTP 网站。 我说吹牛逼，他说我水平不好，二次元斗图乱发，我和他推理半天，他发我一份 NET 优化表，说是优化的。我说 1G 内存再优化也优化不出 C10K 问题。 最后他给出一个域名，我一看 cloudflare，再一看页面，静态就三个字。我问他你这 CDN 缓存 和你 1G 内存，和你的 NET 优化表有什么关联么？和你的 C10K 有什么关联么？ 又是几个表情 这就是春秋笔法。 |
 |
229
yogapants Dec 14, 2021
@sdwgyzyxy 大佬想请教一下分库分表之后如果使用了数据库中间件的话，各种聚合统计、连表操作是不是最好不要用了。因为既然分库分表了说明应该数据量庞大已经完全拆成微服务了，相应的数据库服务器也应该独立开来。再以传统的方式的话意义不大。
|
 |
230
sdwgyzyxy Dec 15, 2021
@yogapants 哈哈，第一次被人称为大佬，其实我就是一个菜鸟，并没有什么经验，就是根据我们项目发的一条感悟，你看看就行了，我经历过拆分 join 的痛，开发人员无视业务表隔离，比如 join 用户表、订单表、流水表，明显的数据表名称前缀都不一样就不要强行 join 了。
|
 |
231
ZX16815 Nov 9, 2023
数据传输一般走内网，传输压力可以忽略不计。
如果能保证，被 join 的表，将来永远不会被分库分表的话，可以 join 。但这个谁也保证不了 |
Select Language