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

2020-06-03 16:47:10 +08:00
 hackingwu

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

33859 次点击
所在节点    程序员
231 条回复
james122333
2020-06-04 14:10:04 +08:00
个人也不太喜欢 sql
效能并没有想像中那么强
语法也反程序员
看来有人跟我一样走大牛的路
ljzxloaf
2020-06-04 14:17:19 +08:00
OLTP 和 OLAP 要分开
zorui
2020-06-04 14:18:09 +08:00
不让使用 join 是 微服务拆分的问题吧。 不同服务下的表不让 join 合理。 同一服务下的不让 join 就说不过去了。
pws22
2020-06-04 14:19:34 +08:00
三张表 一张 文章表 一张 评论表 一张用户表
查询 上海地区的用户 在 6.1 - 6.7 号 没有 发表过评论的用户 分页查询
不用 join 的话 不知道逻辑咋写 大佬们能给点意见么
liuxingdeyu
2020-06-04 14:24:08 +08:00
看业务量吧，通常来说 io 都是性能瓶颈，而解决性能的时候，最好是通过代码的手段，db 最好只是个 db，尽力不要有太多逻辑操作
goodboy95
2020-06-04 14:33:04 +08:00
@huijiewei 好吧，仔细想想的话，你这 3 个 sql 倒也能用，不过我是不打算一直这么搞了，啥时候真要优化了再这么干。
realpg
2020-06-04 14:36:55 +08:00
开发不给力的情况下,禁止 left join 小词典类数据表以外的 join，不算过分。


如果开发都是特别给力的，精通数据库查询优化设计和索引，那无所谓
dawniii
2020-06-04 14:49:33 +08:00
@CRVV 老哥，你这个表结构， [SELECT id FROM tag WHERE name = XXX 取出 tag_id] 这一句可以取出几万个 id，用这几万个 id 再去 in 查询后面的数据这不止是慢吧。
prolic
2020-06-04 14:52:44 +08:00
绝了，看了下，赞同 join 的做的是 erp 之类的企业内部系统，不赞同 join 的都是互联网做 2c 的，这玩意要具体情况具体分析啊
msg7086
2020-06-04 15:21:00 +08:00
@hackingwu #97 数据库 Slave 可以集群，但是数据库集群是有一致性问题的，你往 Master 写数据然后回头从 Slave 读，读出来的不一定是新的值。维护一个 100 台 Slave 的集群比维护 100 台 App server 要难得多。
msg7086
2020-06-04 15:24:22 +08:00
@dawniii #167 取几万个 ID 然后再用 IN 查询为什么会慢，兄弟能不能说说看？
sun1991
2020-06-04 15:40:54 +08:00
@msg7086
#167 取几万个 ID 然后再用 IN 查询为什么会慢，兄弟能不能说说看？
-- 涉及到数据库 IO 操作底层. 有时候按照 ID 逐个读取数据 (即便走索引) 可能比全表扫描花费更多的 IO. 所以数据库层面这块是有优化的, 引擎会决定使用 IO 少的操作来读取数据.
sun1991
2020-06-04 15:43:01 +08:00
@msg7086 Sorry, 看错了. 当我没说.
dawniii
2020-06-04 15:43:39 +08:00
@msg7086 几万只是随便说的一个数字，如果数据量更大呢，然后要在内存里组装一个巨大的 sql 出来吗？还有和直接子查询 select xxxxxx from article where id in(select xxx)好像没啥区别，楼主说也不能用子查询。
hackingwu
2020-06-04 15:44:47 +08:00
@msg7086 我们的应用都是读写分离的，正常写代码的时候就会考虑可能存在延迟。
hackingwu
2020-06-04 15:46:38 +08:00
@zorui 这个我赞同，不同服务下不让 join 合理，考虑不同服务可能会不同的数据库。但是很多公司都是一刀切的规范
hackingwu
2020-06-04 15:47:40 +08:00
@sdwgyzyxy 我们其实主要讨论的是同一个服务的，即同一个库里的表 join
hackingwu
2020-06-04 15:52:13 +08:00
@pangleon 服务内的表 为啥不能 join
wangyzj
2020-06-04 15:59:53 +08:00
@hackingwu #178 其实我还是同意前面有人说的，你们公司可能没有 dba 去负责调优
根据不同业务去设计表格结构很重要
互联网应用会出现很多冗余的数据来避免这种复杂的查询
说白了，因地制宜把
这是一个成本和效率的博弈
Michaelssss
2020-06-04 16:05:20 +08:00
@neilq 哈哈哈哈哈，N 个项目经理会过来赞成你的

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://ex.noerr.eu.org/t/678312

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX