相信很多小伙伴多少都碰到过报表间数据不吻合的问题，有些时候可能是因为统计口径不一致，但有些时候，逻辑上明明应该吻合，却莫名其妙的差那么一点点。
最近碰到一个报表不吻合的案例，原因查明后，发现同样的错误以前也遇到过多次，可见这种错误往往不被重视，当然了，一些小伙伴始终不认为这是一个错误。
案例场景是这样的，挂号费日结的数据跟挂号明细的合计不相符。程序处理逻辑是，先产生需要结账的挂号数据，然后通过点击结账按钮完成结账操作。结账操作使用的是update语句，where条件比产生需要结账数据的条件额外多了时间的限制。很多小伙伴认为这种限制肯定没有问题，但是事实是确实出现了数据不一致。当我提出问题时，有小伙伴说以前从来没有出现过问题，那我只能说我的命“太好”了，每当排查问题的时候，问题就列队欢迎了。
以前我们去医院挂号，基本上唯一的挂号途径就是去医院挂号窗口现场挂号，但是随着互联网的发展，通过手机应用预约挂号越来越被大家接受。案例中操作员点击完产生需要结账的挂号数据，在点击结账按钮完成结账操作之间，虽然保障了现场没有新的挂号数据产生，但是刚好有病人通过网络完成了挂号预约，后台更新结账标志的时候刚好把新产生数据的标志一起给更新了，但是前台产生的结账汇总数据并不包含这笔数据。这样就造成了前台数据显示，跟后台数据更新不一致，也就造成了数据错误。有的小伙伴会说，明明通过时间限制了，但是在多线程与并发面前，没有公共锁的控制的话，并不能完全保障能够通过时间限制住。
有些小伙伴可能会说，哪有这么巧的事情？事实是真的会有这么巧的事。也有一些小伙伴会说，我们跟操作员说了，一定要在晚上23点半之后结账。我想说的是，不能祈求通过限制操作员的操作来弥补程序可能出现的错误。没人会百分百的按照我们的祈求去行事。也不要想当然的以为时间晚点了就没人会预约挂号了。小伙伴们，想想我们自己，有多少人，过了凌晨了，依然还抱着自己的手机不肯睡去。
杜绝这种情况的办法就是，一定要保证前后台数据的一致性，百分百的保障后台更新的数据跟前台显示的数据完全吻合，如果后台直接update无法保障的话，在前台显示的数据集上完成标志位的更新，然后再统一把更新传到后台也是不错的选择。
还是那句话，为了系统性能和数据精准而努力！
