前几天帮同事优化了个SQL,原写法使用多个子查询这里不再重现了,大家都遇到过这样一种情况,在项目后期的维护中, 修改别人的SQL代码,超过30行的语句,多层子查询,读起来很坑,时间久的项目伴随着人员的流通,你可能就不知道原作者写这一堆的SQL是干什么用的, 当然碰到部分有注释习惯的朋友还是好点的,过长的SQL后期维护性与可读性很差,并且一般情况下性能也经不起推敲. 对于长的,复杂的SQL可以有很多种处理方式 1.沉到业务中取处理,拆分SQL 2.抽取公用统计属性,建立冗余表 上边简单列举这两种,…