缘起

    今天早上一到公司，技术支持的小伙就说一个后台报表，计算的任务完成率超过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数据查询，跳过原始的复杂计算逻辑排查