首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
luxinfl
V2EX  ›  程序员

今天改了 bug,看到了一个 sql,顿时惊了。。。。。 这个是新项目,还没上线这部分内容。。

  •  
  •   luxinfl · 33 天前 · 9346 次点击
    这是一个创建于 33 天前的主题,其中的信息可能已经有所发展或是发生改变。
    SELECT
    a.*
    FROM
    (
    SELECT
    a.*
    FROM
    (
    SELECT
    a.*
    FROM
    (
    SELECT
    a.*
    FROM
    (
    SELECT
    a.*
    FROM
    (
    SELECT
    PLATFORM_REQUEST_CODE AS platformRequestCode,
    AGGTEGATE_REQUEST_CODE AS aggtegateRequestCode,
    CREATE_TIME AS createTime,
    STATUS AS payStatus,
    MERCHANT_GENERATE_CODE AS platformCode,
    USER_CODE AS buyCode,
    CHANNEL_NO AS channelNo
    FROM
    tb_aggtegate_payment_request
    WHERE
    STATUS != '00'
    AND DEL_FLAG = 0
    AND IS_VALID = 0
    ORDER BY
    CREATE_TIME DESC
    ) a
    LEFT JOIN ( SELECT CHANNEL_REQUEST_CODE AS channelOrderCode, AGGTEGATE_REQUEST_CODE AS channelaggtegateRequestCode FROM tb_channel_send_report WHERE DEL_FLAG = 0 ) b ON a.aggtegateRequestCode = b.channelaggtegateRequestCode
    ) a
    LEFT JOIN ( SELECT MERCHANT_INFO_CODE, MERCHANT_INFO_NAME AS platformName FROM tb_merchant_info WHERE DEL_FLAG = 0 ) c ON c.MERCHANT_INFO_CODE = a.platformCode
    ) a
    LEFT JOIN ( SELECT PLATFORM_USER_CODE, MERCHANT_NAME AS merchantName FROM tb_user_info WHERE DEL_FLAG = 0 ) b ON a.buyCode = b.PLATFORM_USER_CODE
    ) a
    LEFT JOIN ( SELECT CHANNEL_CODE, CHANNEL_NAME AS channelName FROM tb_channel_info WHERE DEL_FLAG = 0 ) b ON a.channelNo = b.CHANNEL_CODE
    ) a
    LEFT JOIN ( SELECT AGGTEGATE_REQUEST_CODE, TIME_END AS payTime FROM tb_wxpay_order_business WHERE DEL_FLAG = 0 AND IS_VALID = 0 ) b ON a.aggtegateRequestCode = b.AGGTEGATE_REQUEST_CODE
    WHERE
    1 = 1
    85 条回复    2020-07-05 11:27:49 +08:00
    sonice
        1
    sonice   33 天前
    这儿就震惊了?普普通通
    BrettD
        2
    BrettD   33 天前 via iPhone   ❤️ 1
    这一坨怕不是复制粘贴搭出来的😂
    sunziren
        3
    sunziren   33 天前
    ............,√
    ............,×
    jswxg
        4
    jswxg   33 天前
    格式化后看就清楚很多了。

    SELECT a.*
    FROM (
    SELECT a.*
    FROM (
    SELECT a.*
    FROM (
    SELECT a.*
    FROM (
    SELECT a.*
    FROM (
    SELECT PLATFORM_REQUEST_CODE AS platformRequestCode, AGGTEGATE_REQUEST_CODE AS aggtegateRequestCode, CREATE_TIME AS createTime, STATUS AS payStatus, MERCHANT_GENERATE_CODE AS platformCode
    , USER_CODE AS buyCode, CHANNEL_NO AS channelNo
    FROM tb_aggtegate_payment_request
    WHERE STATUS != '00'
    AND DEL_FLAG = 0
    AND IS_VALID = 0
    ORDER BY CREATE_TIME DESC
    ) a
    LEFT JOIN (
    SELECT CHANNEL_REQUEST_CODE AS channelOrderCode, AGGTEGATE_REQUEST_CODE AS channelaggtegateRequestCode
    FROM tb_channel_send_report
    WHERE DEL_FLAG = 0
    ) b
    ON a.aggtegateRequestCode = b.channelaggtegateRequestCode
    ) a
    LEFT JOIN (
    SELECT MERCHANT_INFO_CODE, MERCHANT_INFO_NAME AS platformName
    FROM tb_merchant_info
    WHERE DEL_FLAG = 0
    ) c
    ON c.MERCHANT_INFO_CODE = a.platformCode
    ) a
    LEFT JOIN (
    SELECT PLATFORM_USER_CODE, MERCHANT_NAME AS merchantName
    FROM tb_user_info
    WHERE DEL_FLAG = 0
    ) b
    ON a.buyCode = b.PLATFORM_USER_CODE
    ) a
    LEFT JOIN (
    SELECT CHANNEL_CODE, CHANNEL_NAME AS channelName
    FROM tb_channel_info
    WHERE DEL_FLAG = 0
    ) b
    ON a.channelNo = b.CHANNEL_CODE
    ) a
    LEFT JOIN (
    SELECT AGGTEGATE_REQUEST_CODE, TIME_END AS payTime
    FROM tb_wxpay_order_business
    WHERE DEL_FLAG = 0
    AND IS_VALID = 0
    ) b
    ON a.aggtegateRequestCode = b.AGGTEGATE_REQUEST_CODE
    WHERE 1 = 1
    aaronlam
        5
    aaronlam   33 天前
    这就震惊了,想当年我刚接触到我们公司计费系统的 SQL 代码时,整个人都不好了。
    airplayxcom
        6
    airplayxcom   33 天前   ❤️ 1
    1=1 就很灵性了
    loading
        7
    loading   33 天前 via Android   ❤️ 1
    @airplayxcom 1=1 是标准的拼接 sql 常用技巧
    luxinfl
        8
    luxinfl   33 天前
    @BrettD 不会在上面搞格式,好复杂
    takemeaway
        9
    takemeaway   33 天前
    挺好的项目,就是写这个项目的人脑子太直了
    luxinfl
        10
    luxinfl   33 天前
    @sonice 订单查询的话,量大了不会要很长时间么。性能太差了吧
    luxinfl
        11
    luxinfl   33 天前
    @takemeaway 话说不是不应该用这么多连接么,阿里巴巴开发手册上面还禁止使用连接
    luxinfl
        12
    luxinfl   33 天前
    @jswxg 感觉没差。。sql 这样写真的好么
    est
        13
    est   33 天前   ❤️ 102
    新人和老人的区别就是面对一坨屎山,新人会大吃一斤。老人会贤淑的避开最臭的那部分屎,然后灵巧的在保证屎山不垮的情况下把自己的屎再拉一层上去
    cbasil
        14
    cbasil   33 天前
    太复杂,join 多的查询建视图啊,
    sonice
        15
    sonice   32 天前
    @luxinfl 性能好不好跟索引、数据量、服务器性能等等有关。单看语句的话没啥毛病。
    laminux29
        16
    laminux29   32 天前
    DBA 不懂编程思维,不懂调试测试,写出 shi 一样的 SQL,很正常。

    你受不了可以自己改。
    luxinfl
        17
    luxinfl   32 天前
    @laminux29 这是开发写的,我们小公司,没有 dba
    rtp
        18
    rtp   32 天前
    这才哪到哪,我记得原来的公司,写统计方面的 sql,基本上都是一条语句几屏幕啊……
    soulzz
        19
    soulzz   32 天前
    牛皮 用 sql 语句写业务
    估计真的是老开发才会干的蠢事
    z960112559
        20
    z960112559   32 天前
    @est 666
    Vegetable
        21
    Vegetable   32 天前
    @airplayxcom 1=1 的确挺蛇皮的,我不喜欢,为了保证 where 后边不空添加一个 true,我不敢说这算是技巧,这算是补丁。
    luxinfl
        22
    luxinfl   32 天前
    @soulzz 这是新开发写的。。。把一些字典数据也关联进去查
    luxinfl
        23
    luxinfl   32 天前
    @rtp 上生产环境,直播后台查看订单的,这么搞要出事啊
    526326991
        24
    526326991   32 天前
    就这?
    baozhuo
        25
    baozhuo   32 天前 via iPhone
    这就震惊了?你知道我当初实习的时候见到同事有一个功能,他写了一个接近 6000 行的存储过程的时候有多震惊吗?当时有幸在那个项目组,后来把分配给我的东西做完我就溜了,差点自闭了
    ColoThor
        26
    ColoThor   32 天前
    @baozhuo #25 666
    luxinfl
        27
    luxinfl   32 天前
    @baozhuo 没写过存储过程。。。。
    AmosOvO
        28
    AmosOvO   32 天前   ❤️ 6
    @526326991 到处阴阳怪气,好好讨论的地方,风气都你这种人搞坏了。建议击毙。 @平安程序员
    leonardyang
        29
    leonardyang   32 天前   ❤️ 1
    从 sql 角度看还好吧,主要是写的可读性有点差,我很讨厌一屏都放不完的 sql 。关键是表结构是谁设计的,也是新人? join 多不多不就看表结构设计吗,按学校数据库课程教的那套范式必然一堆 join 啊,从设计时候就应该考虑冗余字段减少关联查询,没有对新人做的表设计做 review ?
    luhe
        30
    luhe   32 天前
    弱弱的问一下,实际开发一般 sql 写多长...
    vxlol
        31
    vxlol   32 天前
    @baozhuo 我能说我写过 8000 行的存储过程么。。。财务系统的标准成本核算~~
    xxlee
        32
    xxlee   32 天前
    left join 取 a.*,这和取最里面那层 select a.* 有啥区别呢?最后再加一个 where 1=1 。。。。 实在无法吐槽
    toesbieya
        33
    toesbieya   32 天前
    为啥会觉得写的没问题啊,这 5 层嵌套 `select` 有什么意义,和 `left join ... left join` 有什么区别
    leonardyang
        34
    leonardyang   32 天前
    @xxlee
    @toesbieya 逐层 left join 可以用前面带出来的字段作为后面 left join 的条件字段,大概算是一个笨办法?这 sql 看得人有点头疼
    EricFuture
        35
    EricFuture   32 天前
    这个还才一屏不到,习惯就好了
    pomelotea2009
        36
    pomelotea2009   32 天前 via Android
    这才 join 五次啊,不过嵌套的五次比较少见。所以开发要对业务有一定的了解,这种情况一般优先考虑把不可变字段做冗余,其次考虑为了取一两个字段要去 join 整个表的那一两个字段做冗余,即使该字段是可变的(当然表少数据量小无所谓)
    xxlee
        37
    xxlee   32 天前   ❤️ 1
    @leonardyang 他这种取法,和最里面那层 a.*是一样的
    Xusually
        38
    Xusually   32 天前
    不知道表结构,索引设置什么的。
    单看 sql 问题似乎不是非常大
    vxlol
        39
    vxlol   32 天前
    这种程度的 SQL 就惊了。。
    比这还夸张的在我以前待的一大型制造企业 ERP 系统里比比皆是~
    业务逻辑基本都在存储过程,随便拎一个就是几百上千行~
    尤其是财务模块,存储过程里面使用游标、递归、动态 SQL 、嵌套执行其它存储过程什么的,都见识过~
    luxinfl
        40
    luxinfl   32 天前
    @pomelotea2009 有三张表是基础信息,其实可以单独在代码里面查询后再匹配塞值。应该比连接三个表要快
    luxinfl
        41
    luxinfl   32 天前
    @vxlol 没见识过。我感觉正经线上的项目,都不会出现这么多的连接
    luxinfl
        42
    luxinfl   32 天前
    @xxlee 其实不太一样,多了一些字段,有三个表是为了用 code 查 name
    magicdu
        43
    magicdu   32 天前 via Android
    太年轻了,见过格式化都格式化不出来的 SQL 吗
    luxinfl
        44
    luxinfl   32 天前
    @Xusually 这样子执行效率不是很低么
    luxinfl
        45
    luxinfl   32 天前
    @magicdu 我是说本站文本框的格式化不会搞,搞不好
    leonardyang
        46
    leonardyang   32 天前   ❤️ 1
    @luxinfl 没看懂你的想法,所谓的匹配塞值不还是要遍历数据吗,莫非你是觉得自己用代码实现的“left join”比现代数据库的查询优化强?互联网公司要求少用 join 是用冗余字段实现的,不是靠在代码里再遍历一遍这种自欺欺人的方式。。。
    Jrue0011
        47
    Jrue0011   32 天前
    看起来中间有几个表目的是为了获取 xxx_name 给前端用于显示,如果在 name 允许用户修改即会改变的情况下,有什么好的做法吗。。。
    nutting
        48
    nutting   32 天前
    sql 就这德性,很恶心的
    winglight2016
        49
    winglight2016   32 天前
    这种子查询嵌套,我们一般用来人工减慢响应时间的,方便以后优化。。。

    哈哈,开玩笑了,不过,子查询是需要尽量避免的吧,实在不行搞个动态视图也好呀。
    Xusually
        50
    Xusually   32 天前
    @luxinfl 光你贴出来的这个 sql 看没有明显的问题。
    执行效率高还是低,肯定还是得看表结构以及索引的安排啊。
    你可以实际执行一下,并且也查看一下这条 sql 在 db 的执行计划,看看情况。
    光看 sql 本身没办法看出来效率有多低
    est
        51
    est   32 天前
    这么多人点赞。怕了怕了。 😂
    x66
        52
    x66   32 天前
    我觉得还好吧,做互联网业务的人跟做 ERP/银行 /保险业务的人平常遇到到的业务复杂度不是同一个级别的。
    LuciferGo
        53
    LuciferGo   32 天前
    真这么写吧,要是每个关联都是命中索引问题倒也不大,丑是丑了点
    594duck
        54
    594duck   32 天前 via iPhone
    @laminux29 你这样喷 DBA 良心不会痛么? DBA 是受过专业训练的好么
    Alexisused
        55
    Alexisused   32 天前
    之前用的报表系统一个报表只能写一个 sql, 最大的那个报表 SQL 写出来压缩之后还有 8K 字符,varchar2 存不下,后来没办法分成了 2 个报表..
    zypy333
        56
    zypy333   32 天前
    看到长 sql 就头大,楼主能贴出来优化后的 sql 吗
    liprais
        57
    liprais   32 天前 via iPhone
    要喷也要看了执行计划做了 profile 再喷
    阿里那手册看看就算了,毕竟 mysql 就那样
    ReinerShir
        58
    ReinerShir   32 天前
    一般是业务复杂,开发时间少,而且对性能没啥要求的后台功能才这么写
    markyangd
        59
    markyangd   32 天前 via iPhone
    见过 3000 行 sp 的人表示,你这个 sql 语句算小菜。
    WytheHuang
        60
    WytheHuang   32 天前
    这样格式化,能看了~
    SELECT
    a.*
    FROM
    (
    SELECT
    a.*
    FROM
    (
    SELECT
    a.*
    FROM
    (
    SELECT
    a.*
    FROM
    (
    SELECT
    a.*
    FROM
    (
    SELECT
    PLATFORM_REQUEST_CODE AS platformRequestCode,
    AGGTEGATE_REQUEST_CODE AS aggtegateRequestCode,
    CREATE_TIME AS createTime,
    STATUS AS payStatus,
    MERCHANT_GENERATE_CODE AS platformCode,
    USER_CODE AS buyCode,
    CHANNEL_NO AS channelNo
    FROM
    tb_aggtegate_payment_request
    WHERE
    STATUS != '00'
    AND DEL_FLAG = 0
    AND IS_VALID = 0
    ORDER BY
    CREATE_TIME DESC
    ) a
    LEFT JOIN ( SELECT CHANNEL_REQUEST_CODE AS channelOrderCode, AGGTEGATE_REQUEST_CODE AS channelaggtegateRequestCode FROM tb_channel_send_report WHERE DEL_FLAG = 0 ) b ON a.aggtegateRequestCode = b.channelaggtegateRequestCode
    ) a
    LEFT JOIN ( SELECT MERCHANT_INFO_CODE, MERCHANT_INFO_NAME AS platformName FROM tb_merchant_info WHERE DEL_FLAG = 0 ) c ON c.MERCHANT_INFO_CODE = a.platformCode
    ) a
    LEFT JOIN ( SELECT PLATFORM_USER_CODE, MERCHANT_NAME AS merchantName FROM tb_user_info WHERE DEL_FLAG = 0 ) b ON a.buyCode = b.PLATFORM_USER_CODE
    ) a
    LEFT JOIN ( SELECT CHANNEL_CODE, CHANNEL_NAME AS channelName FROM tb_channel_info WHERE DEL_FLAG = 0 ) b ON a.channelNo = b.CHANNEL_CODE
    ) a
    LEFT JOIN ( SELECT AGGTEGATE_REQUEST_CODE, TIME_END AS payTime FROM tb_wxpay_order_business WHERE DEL_FLAG = 0 AND IS_VALID = 0 ) b ON a.aggtegateRequestCode = b.AGGTEGATE_REQUEST_CODE
    WHERE
    1 = 1
    xhf1024
        61
    xhf1024   32 天前
    请问你们是基于自己的快速平台开发的嘛
    kiracyan
        62
    kiracyan   32 天前
    看着恐怖而已 逻辑挺简单的
    protectione055
        63
    protectione055   32 天前 via Android
    @leonardyang ??原来学校教的那套范式都没用的吗?刚被数据库这套东西折磨完
    lwlizhe
        64
    lwlizhe   32 天前
    我是个客户端开发,接触的数据库查询没到这个量上

    但是,之前有时被拉去开后端事故总结会的时候,时常听到子查询导致的种种慢查询……(我个人感觉子查询本身没啥问题,应该归属于子查询的查询索引问题吧,不知道这么说对不对)

    记得后端老大还总结了一下数据库查询的几个注意点……可惜现在都忘了……
    hello826
        65
    hello826   32 天前
    这个代码评审能过吗
    xxlee
        66
    xxlee   32 天前
    @luxinfl 你再好好看看,left join 没有 where 条件,是会保留左侧子查询的所有数据的
    KasonPasser
        67
    KasonPasser   32 天前
    @loading #7
    拼接 sql 其实可以写得再简单点 1 就可以了。
    不过还是看着感觉不好。
    loading
        68
    loading   32 天前 via Android
    @KasonPasser 用 1=1 可以满足洁癖在最后替换掉,你用 1 不好做。
    xemtof
        69
    xemtof   32 天前
    @soulzz 我们之前公司的支付部分逻辑全部在数据库写的存储过程做的。
    Qusic
        70
    Qusic   32 天前 via iPhone
    这叫为未来预留优化空间(
    angryfish
        71
    angryfish   32 天前 via iPhone
    @luxinfl #11 不要被阿里什么规范洗脑,适合自己业务的才是最好的。
    rockyou12
        72
    rockyou12   32 天前
    虽然这个 sql 本身就很屎,但 mysql 不支持 with 让这个 sql 更屎了。希望大家以后都不要再用 mysql,pg 真的好用很多……
    gouflv
        73
    gouflv   32 天前 via iPhone
    @est 有画面感了
    rainysia
        74
    rainysia   32 天前
    以前有个 oracle 的师傅...不写代码, 就直接写 SQL 给我。 大概平均一个 select 从开始到结束有个几千行吧。 中间各种生成, 变换, 计算, 叠加。

    跟着写了两年。 各种黑魔法学的盆满钵满
    justin2018
        75
    justin2018   32 天前
    ![8dpdpAv]( )
    NoString
        76
    NoString   32 天前
    哈哈哈 这种在我们组大概会被枪毙
    levelworm
        77
    levelworm   32 天前 via Android
    话说如果是 BI 的话可以考虑用 dbt 这个工具
    cozof
        78
    cozof   32 天前 via iPhone
    以前写存储过程或者看别人的存储过程很多都是上百行,不过这个 abcd 的表别名不怎么样。
    collery
        79
    collery   32 天前
    hive sql 经常这么写。连表查
    lovecy
        80
    lovecy   32 天前
    SELECT a.*
    FROM (
      SELECT a.*
      FROM (
        SELECT a.*
        FROM (
          SELECT a.*
          FROM (
            SELECT a.*
            FROM (
              SELECT
                PLATFORM_REQUEST_CODE AS platformRequestCode
                , AGGTEGATE_REQUEST_CODE AS aggtegateRequestCode
                , CREATE_TIME AS createTime
                , STATUS AS payStatus, MERCHANT_GENERATE_CODE AS platformCode
                , USER_CODE AS buyCode
                , CHANNEL_NO AS channelNo
              FROM tb_aggtegate_payment_request
              WHERE STATUS != '00' AND DEL_FLAG = 0 AND IS_VALID = 0
              ORDER BY CREATE_TIME DESC
            ) `a` LEFT JOIN (
              SELECT CHANNEL_REQUEST_CODE AS channelOrderCode, AGGTEGATE_REQUEST_CODE AS channelaggtegateRequestCode
              FROM tb_channel_send_report WHERE DEL_FLAG = 0
            ) `b` ON a.aggtegateRequestCode = b.channelaggtegateRequestCode
          ) `a` LEFT JOIN (
            SELECT MERCHANT_INFO_CODE, MERCHANT_INFO_NAME AS platformName
            FROM tb_merchant_info
            WHERE DEL_FLAG = 0
          ) `c` ON c.MERCHANT_INFO_CODE = a.platformCode
        ) `a` LEFT JOIN (
          SELECT PLATFORM_USER_CODE, MERCHANT_NAME AS merchantName
          FROM tb_user_info
          WHERE DEL_FLAG = 0
        ) `b` ON a.buyCode = b.PLATFORM_USER_CODE
      ) `a` LEFT JOIN (
        SELECT CHANNEL_CODE, CHANNEL_NAME AS channelName
        FROM tb_channel_info
        WHERE DEL_FLAG = 0
      ) `b` ON a.channelNo = b.CHANNEL_CODE
    ) `a` LEFT JOIN (
      SELECT AGGTEGATE_REQUEST_CODE, TIME_END AS payTime
      FROM tb_wxpay_order_business
      WHERE DEL_FLAG = 0 AND IS_VALID = 0
    ) `b` ON a.aggtegateRequestCode = b.AGGTEGATE_REQUEST_CODE
    WHERE 1 = 1
    lovecy
        81
    lovecy   31 天前
    ```
    啊哈哈哈哈,没有效果啊,白格式化了大半天,貌似 markdown 语法也无效
    ```
    shakoon
        82
    shakoon   31 天前
    说实话我没看懂这个拉屎人的目的,left join 一堆东西但最后都没有用到 join 得到的字段。

    SELECT AA.PLATFORM_REQUEST_CODE AS PLATFORMREQUESTCODE,
    AA.AGGTEGATE_REQUEST_CODE AS AGGTEGATEREQUESTCODE,
    AA.CREATE_TIME AS CREATETIME,
    AA.STATUS AS PAYSTATUS,
    AA.MERCHANT_GENERATE_CODE AS PLATFORMCODE,
    AA.USER_CODE AS BUYCODE,
    AA.CHANNEL_NO AS CHANNELNO
    FROM TB_AGGTEGATE_PAYMENT_REQUEST AA
    LEFT JOIN TB_CHANNEL_SEND_REPORT BB
    ON BB.DEL_FLAG = 0
    AND AA.AGGTEGATE_REQUEST_CODE = BB.CHANNELAGGTEGATEREQUESTCODE
    LEFT JOIN TB_MERCHANT_INFO CC
    ON CC.DEL_FLAG = 0
    AND CC.MERCHANT_INFO_CODE = AA.MERCHANT_GENERATE_CODE
    LEFT JOIN TB_USER_INFO DD
    ON DD.DEL_FLAG = 0
    AND AA.USER_CODE = DD.PLATFORM_USER_CODE
    LEFT JOIN TB_CHANNEL_INFO EE
    ON EE.DEL_FLAG = 0
    AND AA.CHANNEL_NO = EE.CHANNEL_CODE
    LEFT JOIN TB_WXPAY_ORDER_BUSINESS FF
    ON FF.DEL_FLAG = 0
    AND FF.IS_VALID = 0
    AND AA.AGGTEGATE_REQUEST_CODE = FF.AGGTEGATE_REQUEST_CODE
    WHERE AA.STATUS != '00'
    AND AA.DEL_FLAG = 0
    AND AA.IS_VALID = 0
    ORDER BY AA.CREATE_TIME DESC
    shakoon
        83
    shakoon   31 天前
    @xxlee #32 @xxlee #37 没错,我整理了一下,发现这坨屎的核心也就中间那十行
    @luxinfl #42 查不查到 name 有什么关系呢,最后的结果集并没有 name,所有的 join 都没有用处,反而可能会导致结果集数量上有增加,里面若干重复的数据
    realpg
        84
    realpg   31 天前
    以前在一个公司招聘 PHP,有一个 JAVA 开发商业软件转过来的大佬。

    面试题有一个数据库结构跟所要的查询结果格式比较蹩脚的题,基本考察就是性能考虑,这么进行交叉,循环设计

    这个大佬拿笔记本摆弄了半天,非常牛逼的特意给我炫耀他接这题的方式,一条 2KB 的 SQL 语句拼接……

    那还是跑在笔记本的测试库下本身也就几十万数据量下,一个查询卡了能有 0.5 秒……
    pydiff
        85
    pydiff   31 天前
    是我的话我直接扔回给写的人,看着就觉得恶心
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4119 人在线   最高记录 5168   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 32ms · UTC 06:41 · PVG 14:41 · LAX 23:41 · JFK 02:41
    ♥ Do have faith in what you're doing.