V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
ericcen
V2EX  ›  问与答

单表多次查(业务层)和复杂 sql 查询(有 join、子查询)大家更倾向哪种方案,两者优劣势有哪些

  •  1
     
  •   ericcen · 2023-08-24 22:18:18 +08:00 · 1903 次点击
    这是一个创建于 489 天前的主题,其中的信息可能已经有所发展或是发生改变。
    16 条回复    2023-08-25 10:34:35 +08:00
    xipushi
        1
    xipushi  
       2023-08-24 22:41:50 +08:00 via Android
    看情况。有人坚持让我咋用就咋用,都可以。我更喜欢把数据干到一个表,一个 SQL 搞定。

    单表多次查,代码里面实现 jion , 很难懂。数据库服务器压力小。

    复杂 SQL ,会导致数据库服务器 cpu I/O 高。 但我觉得你业务代码里面 join 不一定比数据库性能好,只是把 cpu I/O 消耗转移到业务服务器了。
    512357301
        2
    512357301  
       2023-08-24 23:42:14 +08:00 via Android
    我倾向于复杂 SQL ,见过每秒几百次请求接口的,数据库没疯,后端先疯了,一问是前端不知道要批量查询接口,把点查接口当批查接口用了。
    再说了都有 join 和子查询了,你貌似没得选,查询速度肯定慢,只不过是把压力转移到哪里的问题。
    如果本地 join 的话,那需要先多次批量查询,把多份数据集存到本地内存,然后内存里做 join ,性能差的话,可以加机器解决,比分库分表简单一些(这也是现在 nosql 数据库常用的方案)。
    但是真用到多表 join 了,那还不如查询的时候直接请求大数据的接口呢,他们算力足。
    lsk569937453
        3
    lsk569937453  
       2023-08-24 23:53:53 +08:00 via Android
    用 join 和子查询就是把压力放到数据库。数据库可是有状态的,不能随意扩容。流量上来了,你就抓瞎了。第一种方案在服务端做,代码复杂,但是无状态的服务扩容简单。

    所以互联网很少用 join ,我甚至记得去哪的数据库规范里禁止 join 。
    jackOff
        4
    jackOff  
       2023-08-24 23:55:57 +08:00 via Android
    Join ,单表搞得太复杂你也会懵逼的,而且有时候你的查询数据范围很少,但是你是全部存一张表,那你就要按照条件去全表查询,这个耗时就有点搞事了
    jokechen
        5
    jokechen  
       2023-08-25 00:01:13 +08:00
    我倾向于单表多次查,前段时间刚刚做了一个账单的业务,数据没有冗余,如果做连表查询,要关联 5 张表一起,每个表的字段名称还不一样,要查的内容的逻辑也不一样,总之联表查询没有 150 行是下不来了。
    行数多还没什么,关键的是后续可维护性太差。
    在应用端对数据进行整理操作的话,只要抽象、封装做得好,代码维护还是相对容易一些的。
    Bingchunmoli
        6
    Bingchunmoli  
       2023-08-25 00:43:42 +08:00 via Android
    看应用层是否是集群(例如我们 k8s 应用层),sql 层是否已经是瓶颈(我们一般买的阿里云的 rds 配置不算高),测试过集群情况下不如应用层合并,单体架构下通常连表效率更高,除非 sql 已经瓶颈,而应用压力较小
    Worldispow
        7
    Worldispow  
       2023-08-25 06:10:52 +08:00 via Android
    看数据库性能,mysql 的话最好在把逻辑放到代码里,oracle 的话可以随便折腾
    echo1937
        8
    echo1937  
       2023-08-25 08:55:49 +08:00
    寻找 “数据库查询性能 vs 数据库网络 IO 开销 vs SQL 可维护性”三者的平衡。

    SQL 的可维护性是远低于常见高级语言的,只要不会把数据库干挂,一般选择代码维护最简单的方法,性能后期慢慢优化。
    opengps
        9
    opengps  
       2023-08-25 09:09:49 +08:00
    我通常推荐单表多次查,除非有证据表明这个表未来不怎么增长,一定是一个表够用不用拆分优化
    8355
        10
    8355  
       2023-08-25 09:10:31 +08:00
    肯定是第一种,其实并不会慢,而且可以通过代码进行优化,加缓存或者并发查。
    如果你可以用 olap 也不会问这个问题了。
    nothingistrue
        11
    nothingistrue  
       2023-08-25 09:21:14 +08:00
    两个都是垃圾,比较它俩的优劣是底层互害的行为。当业务/产品和上层架构都是良好的时候,你是不会遇到单表多次查的,复杂 sql 查询可能有但它肯定会被限制在基础设施层(业务层编码人员是看不到也无需理会的)。
    chuck1in
        12
    chuck1in  
       2023-08-25 09:32:59 +08:00
    join 多了你很难优化性能的。
    huijiewei
        13
    huijiewei  
       2023-08-25 09:38:34 +08:00
    JOIN 多了复杂且难以优化,还得要专门的 DBA 。
    单表多次就简单暴力多了。灵活性拉满
    YK46PTT
        14
    YK46PTT  
       2023-08-25 09:48:42 +08:00 via iPhone
    以前可能用 SQL 一把梭,现在得区分情况,好维护的用 SQL 不好维护的用单表多次查
    adoal
        15
    adoal  
       2023-08-25 10:19:31 +08:00
    如果对数据一致性有强要求的话,第一种可能不太靠谱
    silencil
        16
    silencil  
       2023-08-25 10:34:35 +08:00
    学到了 以后我也试试单表查。不过单表查询,业务代码中再组合数据感觉业务代码有点乱啊
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5490 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 07:02 · PVG 15:02 · LAX 23:02 · JFK 02:02
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.