昨天更新统计大屏，客户说累计旅客人数没有四舍五入。顿时感觉奇怪，因为从来只更新年月，数据都是程序去数据库里面现捞的，这个系统都用了好几年了，要错也应该都改过了。查了一下正确的数据，确实是要四舍五入的。
于是就把涉及累计旅客人数的sql语句刨出来看，先除以10000，做单位转换，再round四舍五入，再用decimal取一位小数，看上去没问题啊？
然后把没处理之前的数据选出来看，好吧，这个数字不对。正确的旅客人数除以10000小数点后两位是75，要四舍五入到8，而这个数字除以10000后小数点后两位是74，刚好舍掉了。
看看统计人数的sql，也好像没错，把成人、儿童、过站的相加，一直都是这么算的。
为什么会选出来的数据相差几百人呢？
灵光一闪，想到了上次去跟客户沟通报表的时候讲到的运输性质的问题，他们要的统计数据，架次是要运输性质的，旅客货邮是要所有性质的。什么正班，加班，补班，包机，换飞机，备降都算运输性质，其它的什么公务，试飞，人工降雨，驾照培训，空中游览，救灾之类的只有在统计起降架次的时候才算进去。相比起降架次，人家更看重运输起降架次。
而这个sql选数据是根据运输性质一起选的，只统计了航班性质为运输的旅客，当然结果不一样。可以想象，货邮的数字也不一样。但是统计的结果旅客吞吐量单位用的万人次，货邮吞吐量用的万吨，每次都要先除然后取小数点后一位，而且两者数据量本来就相差不大，所以问题才一直没有暴露出来。
报表也是这样，铁打的报表流水的开发，前任没调研清楚到底哪个数据是怎么个算法，客户默认我们知道，因为一期的报表是OK的，等开始用二期的时候就接到抱怨说哪个报表的数据不对，新增的几张表都没办法用。然后继任者就开始新一轮填坑。
要跳出这个死循环，就只有靠需求调研和懂业务这两把刷子了。