V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
payboy
V2EX  ›  Java

业务多表 join,单条 SQL 梭哈一把好还是多次查询在代码整合好

  •  
  •   payboy · 2019-04-22 13:51:19 +08:00 · 5397 次点击
    这是一个创建于 2021 天前的主题,其中的信息可能已经有所发展或是发生改变。
    有些类似报表的业务需求,通常是十几张表 join 查询,写成一条非常长的 SQL。
    从代码层面看,查询即所求,简单但难看。
    如果从效能方面看,单条 SQL 是不是比较好。
    第 1 条附言  ·  2019-04-22 14:43:18 +08:00
    SQL 走索引,有一两张千万级的表,可能有子查询
    26 条回复    2019-04-23 20:03:33 +08:00
    kevinhwang
        1
    kevinhwang  
       2019-04-22 13:55:44 +08:00
    你能这么问证明你团队无约束。
    如果外包请疯狂 join 表然后愉快玩耍。
    后续要自己维护的请慎重!!!
    zarvin
        2
    zarvin  
       2019-04-22 13:58:16 +08:00
    我公司后台开发好像就是很多 join,那 sql 语句贼长
    YzSama
        3
    YzSama  
       2019-04-22 14:11:10 +08:00 via iPhone
    我宁愿分开查,增加缓存。。
    passion336699
        4
    passion336699  
       2019-04-22 14:11:14 +08:00


    是这种吗, 下面还有很多很多截不完了....
    NoKey
        5
    NoKey  
       2019-04-22 14:12:16 +08:00
    我们这里一般都是分开,然后在编程语言里自行查找组合需要的数据
    adzchao
        6
    adzchao  
       2019-04-22 14:13:58 +08:00
    @passion336699 这不是很正常么 我感觉你这还不是复杂的
    onepunch
        7
    onepunch  
       2019-04-22 14:14:46 +08:00
    小表问题不大。如果表增长无法预期你还是别这么做了
    rockyou12
        8
    rockyou12  
       2019-04-22 14:16:58 +08:00
    统计业务请一定用代码来写,千万别 join N 级。像我们很多 1000 多行,子查询 3、4、5 层的 sql 完全没办法维护……
    Mmiracle110
        9
    Mmiracle110  
       2019-04-22 14:17:21 +08:00
    join 表多的话,表内数据小还好,表大的话,你试试......
    sjzzz
        10
    sjzzz  
       2019-04-22 14:20:26 +08:00
    ....建议换一个团队。
    VensonEEE
        11
    VensonEEE  
       2019-04-22 14:21:27 +08:00
    你们怕啥没见过两万多字的 sql,存储过程。以前某行业应用,报表系统,全 oracle 存储过程,改个逻辑要重写一个星期。 真是佩服 oracle 的性能。
    payboy
        12
    payboy  
    OP
       2019-04-22 14:33:17 +08:00
    @passion336699 是的,复杂点还有各种子查询。
    Mazexal
        13
    Mazexal  
       2019-04-22 14:45:57 +08:00
    第一, 不好做缓存优化
    第二, 增加维护成本
    第三, 不适合后期做分库分表
    第四, 不适合做 sql 查询优化
    优势: 一开始写的速度快那么一丢丢
    结论你自己想吧
    est
        14
    est  
       2019-04-22 15:23:41 +08:00
    JOIN 没啥不好的。

    无脑 JOIN。。。只要 dba 角色那个人能管理得过来也挺好的。
    waising
        15
    waising  
       2019-04-22 15:38:48 +08:00
    @Mazexal #13 关于 sql 优化,平时是没有用 orm 吗?如果是单表的话感觉 orm 的优势也不大了啊
    guyujiezi
        16
    guyujiezi  
       2019-04-22 15:41:22 +08:00
    join 挺好的,SQL 语句越拼越有意思,还可以为将来系统优化什么的创造 KPI
    Removable
        17
    Removable  
       2019-04-22 15:47:01 +08:00
    @rockyou12 #8 别说了,我接手的有个模块,之前做的那个沙雕把所有的业务都放到存储过程里了,那维护起来就一言难尽
    DiverRD
        18
    DiverRD  
       2019-04-22 16:19:02 +08:00
    join 一时爽,迁移火葬场
    xuanbg
        19
    xuanbg  
       2019-04-22 17:35:33 +08:00
    都不会写 sql 吗?几个表 join 就把你们吓坏了?只要单表数据量不上千万级别,join 上 10 来个表数据也能秒出好不好。

    话说单表数据量要是上千万级别的,做表结构设计的那个可以解雇了。
    tiedan
        20
    tiedan  
       2019-04-22 18:49:18 +08:00
    我选择 join
    zhchyu999
        21
    zhchyu999  
       2019-04-22 18:52:14 +08:00
    后台就怎么爽怎么来,量大 mysql 还是简单查询比较好
    mk0114
        22
    mk0114  
       2019-04-22 20:26:54 +08:00
    可是有些分页或者过滤一定要联合其他表查询该怎么办呢?
    glacer
        23
    glacer  
       2019-04-22 20:32:33 +08:00
    统计型 SQL 敢在业务数据库上跑?不怕分分钟拖垮掉?
    lvchao
        24
    lvchao  
       2019-04-23 09:17:18 +08:00
    不用多表 join 对于分页怎么处理
    gosansam
        25
    gosansam  
       2019-04-23 12:49:45 +08:00
    写过一段上午写好 睡个午觉起来就看不懂的 sql 了 join 也就七八个 然后子查询一堆
    jianmo1997
        26
    jianmo1997  
       2019-04-23 20:03:33 +08:00
    在我司前一种方式一般都会被 DBA 杀了祭天
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1207 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 18:28 · PVG 02:28 · LAX 11:28 · JFK 14:28
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.