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

[luxinfl]

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

[sonice]

这儿就震惊了？普普通通

[BrettD]

这一坨怕不是复制粘贴搭出来的😂

[sunziren]

............，√
............，×

[jswxg]

格式化后看就清楚很多了。

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]

这就震惊了，想当年我刚接触到我们公司计费系统的 SQL 代码时，整个人都不好了。

[airplayxcom]

1=1 就很灵性了

[loading]

@airplayxcom 1=1 是标准的拼接 sql 常用技巧

[luxinfl]

@BrettD 不会在上面搞格式，好复杂

[takemeaway]

挺好的项目，就是写这个项目的人脑子太直了

[luxinfl]

@sonice 订单查询的话，量大了不会要很长时间么。性能太差了吧

[luxinfl]

@takemeaway 话说不是不应该用这么多连接么，阿里巴巴开发手册上面还禁止使用连接

[luxinfl]

@jswxg 感觉没差。。sql 这样写真的好么

[est]

新人和老人的区别就是面对一坨屎山，新人会大吃一斤。老人会贤淑的避开最臭的那部分屎，然后灵巧的在保证屎山不垮的情况下把自己的屎再拉一层上去

[cbasil]

太复杂，join 多的查询建视图啊，

[sonice]

@luxinfl 性能好不好跟索引、数据量、服务器性能等等有关。单看语句的话没啥毛病。

[laminux29]

DBA 不懂编程思维，不懂调试测试，写出 shi 一样的 SQL，很正常。

你受不了可以自己改。

[luxinfl]

@laminux29 这是开发写的，我们小公司，没有 dba

[rtp]

这才哪到哪，我记得原来的公司，写统计方面的 sql，基本上都是一条语句几屏幕啊……

[soulzz]

牛皮 用 sql 语句写业务
估计真的是老开发才会干的蠢事

[z960112559]

@est 666

[Vegetable]

@airplayxcom 1=1 的确挺蛇皮的，我不喜欢，为了保证 where 后边不空添加一个 true，我不敢说这算是技巧，这算是补丁。

[luxinfl]

@soulzz 这是新开发写的。。。把一些字典数据也关联进去查

[luxinfl]

@rtp 上生产环境，直播后台查看订单的，这么搞要出事啊

[526326991]

就这？

[baozhuo]

这就震惊了？你知道我当初实习的时候见到同事有一个功能，他写了一个接近 6000 行的存储过程的时候有多震惊吗？当时有幸在那个项目组，后来把分配给我的东西做完我就溜了，差点自闭了

[ColoThor]

@baozhuo #25 666

[luxinfl]

@baozhuo 没写过存储过程。。。。

[AmosOvO]

@526326991 到处阴阳怪气，好好讨论的地方，风气都你这种人搞坏了。建议击毙。 @平安程序员

[leonardyang]

从 sql 角度看还好吧，主要是写的可读性有点差，我很讨厌一屏都放不完的 sql 。关键是表结构是谁设计的，也是新人？ join 多不多不就看表结构设计吗，按学校数据库课程教的那套范式必然一堆 join 啊，从设计时候就应该考虑冗余字段减少关联查询，没有对新人做的表设计做 review ？

[luhe]

弱弱的问一下，实际开发一般 sql 写多长...

[vxlol]

@baozhuo 我能说我写过 8000 行的存储过程么。。。财务系统的标准成本核算~~

[xxlee]

left join 取 a.*，这和取最里面那层 select a.* 有啥区别呢？最后再加一个 where 1=1 。。。。 实在无法吐槽

[toesbieya]

为啥会觉得写的没问题啊，这 5 层嵌套 `select` 有什么意义，和 `left join ... left join` 有什么区别

[leonardyang]

@xxlee
@toesbieya 逐层 left join 可以用前面带出来的字段作为后面 left join 的条件字段，大概算是一个笨办法？这 sql 看得人有点头疼

[EricFuture]

这个还才一屏不到，习惯就好了

[pomelotea2009]

这才 join 五次啊，不过嵌套的五次比较少见。所以开发要对业务有一定的了解，这种情况一般优先考虑把不可变字段做冗余，其次考虑为了取一两个字段要去 join 整个表的那一两个字段做冗余，即使该字段是可变的(当然表少数据量小无所谓)

[xxlee]

@leonardyang 他这种取法，和最里面那层 a.*是一样的

[Xusually]

不知道表结构，索引设置什么的。
单看 sql 问题似乎不是非常大

[vxlol]

这种程度的 SQL 就惊了。。
比这还夸张的在我以前待的一大型制造企业 ERP 系统里比比皆是~
业务逻辑基本都在存储过程，随便拎一个就是几百上千行~
尤其是财务模块，存储过程里面使用游标、递归、动态 SQL 、嵌套执行其它存储过程什么的，都见识过~

[luxinfl]

@pomelotea2009 有三张表是基础信息，其实可以单独在代码里面查询后再匹配塞值。应该比连接三个表要快

[luxinfl]

@vxlol 没见识过。我感觉正经线上的项目，都不会出现这么多的连接

[luxinfl]

@xxlee 其实不太一样，多了一些字段，有三个表是为了用 code 查 name

[magicdu]

太年轻了，见过格式化都格式化不出来的 SQL 吗

[luxinfl]

@Xusually 这样子执行效率不是很低么

[luxinfl]

@magicdu 我是说本站文本框的格式化不会搞，搞不好

[leonardyang]

@luxinfl 没看懂你的想法，所谓的匹配塞值不还是要遍历数据吗，莫非你是觉得自己用代码实现的“left join”比现代数据库的查询优化强？互联网公司要求少用 join 是用冗余字段实现的，不是靠在代码里再遍历一遍这种自欺欺人的方式。。。

[Jrue0011]

看起来中间有几个表目的是为了获取 xxx_name 给前端用于显示，如果在 name 允许用户修改即会改变的情况下，有什么好的做法吗。。。

[nutting]

sql 就这德性，很恶心的

[winglight2016]

这种子查询嵌套，我们一般用来人工减慢响应时间的，方便以后优化。。。

哈哈，开玩笑了，不过，子查询是需要尽量避免的吧，实在不行搞个动态视图也好呀。

[Xusually]

@luxinfl 光你贴出来的这个 sql 看没有明显的问题。
执行效率高还是低，肯定还是得看表结构以及索引的安排啊。
你可以实际执行一下，并且也查看一下这条 sql 在 db 的执行计划，看看情况。
光看 sql 本身没办法看出来效率有多低

[est]

这么多人点赞。怕了怕了。 😂

[x66]

我觉得还好吧，做互联网业务的人跟做 ERP/银行 /保险业务的人平常遇到到的业务复杂度不是同一个级别的。

[LuciferGo]

真这么写吧，要是每个关联都是命中索引问题倒也不大，丑是丑了点

[594duck]

@laminux29 你这样喷 DBA 良心不会痛么？ DBA 是受过专业训练的好么

[Alexisused]

之前用的报表系统一个报表只能写一个 sql, 最大的那个报表 SQL 写出来压缩之后还有 8K 字符，varchar2 存不下，后来没办法分成了 2 个报表..

[zypy333]

看到长 sql 就头大,楼主能贴出来优化后的 sql 吗

[liprais]

要喷也要看了执行计划做了 profile 再喷
阿里那手册看看就算了,毕竟 mysql 就那样

[ReinerShir]

一般是业务复杂，开发时间少，而且对性能没啥要求的后台功能才这么写

[markyangd]

见过 3000 行 sp 的人表示，你这个 sql 语句算小菜。

[WytheHuang]

这样格式化，能看了~
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]

请问你们是基于自己的快速平台开发的嘛

[kiracyan]

看着恐怖而已 逻辑挺简单的

[protectione055]

@leonardyang ？？原来学校教的那套范式都没用的吗？刚被数据库这套东西折磨完

[lwlizhe]

我是个客户端开发，接触的数据库查询没到这个量上

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

记得后端老大还总结了一下数据库查询的几个注意点……可惜现在都忘了……

[hello826]

这个代码评审能过吗

[xxlee]

@luxinfl 你再好好看看，left join 没有 where 条件，是会保留左侧子查询的所有数据的

[KasonPasser]

@loading #7
拼接 sql 其实可以写得再简单点 1 就可以了。
不过还是看着感觉不好。

[loading]

@KasonPasser 用 1=1 可以满足洁癖在最后替换掉，你用 1 不好做。

[xemtof]

@soulzz 我们之前公司的支付部分逻辑全部在数据库写的存储过程做的。

[Qusic]

这叫为未来预留优化空间（

[angryfish]

@luxinfl #11 不要被阿里什么规范洗脑，适合自己业务的才是最好的。

[rockyou12]

虽然这个 sql 本身就很屎，但 mysql 不支持 with 让这个 sql 更屎了。希望大家以后都不要再用 mysql，pg 真的好用很多……

[gouflv]

@est 有画面感了

[rainysia]

以前有个 oracle 的师傅...不写代码， 就直接写 SQL 给我。 大概平均一个 select 从开始到结束有个几千行吧。 中间各种生成， 变换， 计算， 叠加。

跟着写了两年。 各种黑魔法学的盆满钵满

[justin2018]


[NoString]

哈哈哈 这种在我们组大概会被枪毙

[levelworm]

话说如果是 BI 的话可以考虑用 dbt 这个工具

[cozof]

以前写存储过程或者看别人的存储过程很多都是上百行，不过这个 abcd 的表别名不怎么样。

[collery]

hive sql 经常这么写。连表查

[lovecy]

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]

```
啊哈哈哈哈，没有效果啊，白格式化了大半天，貌似 markdown 语法也无效
```

[shakoon]

说实话我没看懂这个拉屎人的目的，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]

@xxlee #32 @xxlee #37 没错，我整理了一下，发现这坨屎的核心也就中间那十行
@luxinfl #42 查不查到 name 有什么关系呢，最后的结果集并没有 name，所有的 join 都没有用处，反而可能会导致结果集数量上有增加，里面若干重复的数据

[realpg]

以前在一个公司招聘 PHP，有一个 JAVA 开发商业软件转过来的大佬。

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

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

那还是跑在笔记本的测试库下本身也就几十万数据量下，一个查询卡了能有 0.5 秒……

[pydiff]

是我的话我直接扔回给写的人,看着就觉得恶心