多层for循环嵌套使用sql优化

哇,已经有一年多没有写了

这里来记录一下一个小小的优化

原因:领导线上查看RDS监控数据和ECS监控曲线,发现每天凌晨2点cpu使用率激增

       

      从图可以看出来很有规律性,可以知道这是某个定时脚本的原因,根据执行时间可以定位到该定时脚本。看一看定时脚本的逻辑原来这个脚本是对过去30天每一天--每种票类型--每个省份完成订单总数和售票总数的统计和更新。这里附上一段代码截图

       可以看出来之前代码套了3层for循环,按照每天去循环查每种票类型对应每一个省份的逻辑,从order(订单表)中依次统计对应create_time,order_type,province匹配并且订单状态为已完成的订单数和售票数,存在即更新不存在则插入的逻辑更新order_source(客源地订单统计表)。一共执行了 30(天)*8(票类型)*34(省份)*3(统计+查是否存在+更新/插入)=24480条sql语句。

        如果一开始让我实现这个功能我的思路可能也是按照如果订单创建,无论订单的状态什么时候更新为已完成,这个订单始终是订单创建那一天完成的订单。之所以要不断更新过去30天的数据是因为存在这样的情况,比如用户提前一周比如4.5买好票,但是5.5号才消费也就是5.5号订单状态才变为已完成。为了统计到这一个完成的订单要花费好多次无用的查询。

       优化后的逻辑。是按照订单完成的update_time字段来查询,不管你的订单是什么时候创建的,订单什么时候更新就属于更新的那一天完成的订单。所以我们可以只统计前一天订单状态更新为已完成的订单,按照update_time进行查询,按照省份,订单类型,更新时间进行分组GroupBy("order_province,type,date_format(update_time, '%Y-%m-%d')"),我们就可以查出前一天已完成订单的省份,类型,时间,然后将数据进行拼接insert sql语句,只需要两条sql语句可以完成统计。上线后cpu使用如下图,可以看出使用cpu低了好多,效果很明显

 

优化思路:1.避免在for循环中使用sql

                  2.充分理解业务需求

  • 2
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值