首先提示：我不知道答案
总部做了一个页面，可以让我们查数据，但是我发现了一个神奇的 BUG：

不设置范围的时候可以看到一项值为7234128.60的数据
筛选范围为7000000~7300000时仍然可以搜到
筛选范围为7200000~7300000的时候就搜不到了

看前端请求参数是请求的"7200000"这样的字符串，可惜忘记看返回数据的形式了。
现在页面临时下线，纠结了半天是怎么实现这样的 BUG 的。有没有大佬遇到过类似的问题？

后端什么语言？是否发生了类型转换？

用 curl 测测 api ，能复现就是后端的 bug ，不能复现就是前端的 bug

＃1 后端是 Java ，数据库不太清楚，不过肯定是国产的。

＃2 是后端 Bug ，筛选之后返回确实是空的。

会不会是由于缓存问题？或者这条数据已经被删除了？

首先，能保证查询的数据集合本身是不变的吗？

也就是没人操作这个表里面数据的新增和删减之类的操作

看一下数据库的数据格式是不是字符串
如果不是，再查一下 java 查询的时候是不是当字符串传进去的

＃5 ＃6
不会的，这个数字其实就是一笔交易的金额，我每种条件筛了好几次都是有问题。
（其实还有更大的问题，按名字筛选会漏掉部分数据）

＃7 看起来是按照字符串排序导致的，但具体是哪里就得摸查一下了

＃7 可惜我只是异地部门的小员工，看不了。

没有日志吗

＃8 那就要看是业务逻辑处理返回的时候有问题（比如上面说的 js/后端 java 处理格式之类的），还是数据库本身的返回结果有问题了。都不是没可能，谁知道底下代码是怎么写的（

都无从猜起（

＃12 哈哈哈，就是因为无从下手，所以一个人想了半天想不出。

＃11 没有，单反能正向查，我都不会反向想这么久，哈哈哈。

int/long 越界？

首先通过测试不断的确定到底什么参数能精确返回或精确不返回这个值，二分法不断分割
另外考虑上下界的问题
比如：7200000~7300000 这个查不出来，7199999~7300000 这个呢？

只要不是偶现问题，通过这种方法一定能找到一个确定的边界，要么进入这个边界就能查出来，要么就是进入这个边界一定查不出来
等确定好这个边界，才好推测

float 越界了

分布式数据库？

神奇的 bug 就别拿上来说浪费大家时间了，谁知道是不是压根后端筛选的字段就跟前端不是同一个。比如说后端 filter 的数字其实是另一个税后栏位本来就是小于 7200000 的。
自己看吧，解决了再发上来给我们乐乐。

可能有一个用于快速查询的百万位缓存(数据库或缓存),这个位存的时候没有进位,但是查询的时候值被进位了
如果你们订单都是百万级别的话,这个想法还是好的,但入库/查询没对齐,测试还没复现
虽然这么做个人觉得收益不大