今天改了 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

[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 有三张表是基础信息，其实可以单独在代码里面查询后再匹配塞值。应该比连接三个表要快