缘起
今天早上一到公司,技术支持的小伙就说一个后台报表,计算的任务完成率超过100%,有异常,客户要用,比较急,要解决这个问题。
解决过程
自从接了上任的报表计算,这个就头疼,没办法硬着头皮查什么原因,报表的SQL比较简单,一个查:接受任务数表a, 一个查:完成任务数表b
a和b表,都是直接计算的结果表。
第一步: 看看是否原始查询报表的导致数据缺少,如join,left join登,去掉相关表的关联,修改join如left join,看看数据是否有变化,
修改完,数据还是没变化,确认不是SQL关联和join表的问题
第二步: 单独拿出执行的SQL,为了取到合适的SQL,特意开了腾讯云的云审计,查询后获取完整的SQL,单独查询“”接收任务数“和“”完成任务数”,
单独查询查出的数据和上面的显示是一样的,看计算的存储过程,也复杂,找不到是存储过程哪错,怎么知道计算数据是错的。 怎么处理?
这就陷入的困境,不知道计算的数据哪个是错的,可能2个多错,可能其中只有一个错的,怎么排查?这时技术支持有提示新信息,感觉这个问题必须解决。
弄了一阵子,没有头绪,感觉就烦,这个事情也没什么意思,都是多少年前的问题还遗留到现在出现,出现抵触的心情。但是事情要解决!
心静了一下,分析了一下,2个数据到底是哪个出现问题,还是复杂的存储过程计算逻辑有bug,先从哪里入手?
这些数据,就这个完成任务数据大,是否可以先查这个任务完成数据,根据常识,先暂且认为接收任务数是对的,先把完成任务完成数据排查清楚(计算清楚)
接着就把计算完成任务数,计算SQL整理出来,使用最原始的SQL,查询出结果,发现和计算的结果不一致,结果只有7600多,少于新任务数的7700多,更是少于计算的8400多的原来结果
这样确认了计算结果出现问题,就用原始的计算SQL,从新repalce into替换原来的老数据,查询报表发现还是有问题,原来表中有2个日期(任务日期task_date,完成日期finish_date),我只通过finish_date写入替换,历史的数据task_date的确有些数据,但是这个都是完成历史数据,和这个任务日期无关,查了一下,的确可以删除掉,执行下面SQL清理垃圾数据OK
delete from b where task_date>='2024-04-01' and task_date <= '2024-04-28'
执行后,报表的完成数据已经OK
总结
1, 遇事情不要急躁和退却,只会添加烦劳,对解决问题毫无帮助
2,当不知道如何入手时,可以根据常识去判断,从最容易出错的地方入手,减少排查面
3,使用了中间结果,可以直接用原始SQL数据查询,跳过原始的复杂计算逻辑排查
标签:报表,异常,查询,计算,SQL,date,数据 From: https://www.cnblogs.com/zping/p/18165657