这是一个创建于 367 天前的主题，其中的信息可能已经有所发展或是发生改变。
首先提示：我不知道答案
总部做了一个页面，可以让我们查数据，但是我发现了一个神奇的 BUG：
- 不设置范围的时候可以看到一项值为
7234128.60的数据 - 筛选范围为
7000000~7300000时仍然可以搜到 - 筛选范围为
7200000~7300000的时候就搜不到了
看前端请求参数是请求的"7200000"这样的字符串，可惜忘记看返回数据的形式了。
现在页面临时下线，纠结了半天是怎么实现这样的 BUG 的。有没有大佬遇到过类似的问题？
 |
1
duanxianze 2024-12-06 16:10:03 +08:00
后端什么语言？是否发生了类型转换？
|
 |
2
Ayanokouji 2024-12-06 16:10:35 +08:00
用 curl 测测 api ，能复现就是后端的 bug ，不能复现就是前端的 bug
|
 |
3
arect OP @duanxianze #1 后端是 Java ，数据库不太清楚，不过肯定是国产的。
|
|
4
arect OP @Ayanokouji #2 是后端 Bug ，筛选之后返回确实是空的。
|
 |
5
h1298841903 2024-12-06 16:55:16 +08:00
会不会是由于缓存问题？或者这条数据已经被删除了？
|
 |
6
luciankaltz 2024-12-06 16:58:38 +08:00
首先，能保证查询的数据集合本身是不变的吗？
也就是没人操作这个表里面数据的新增和删减之类的操作 |
 |
7
newaccount 2024-12-06 17:01:29 +08:00
看一下数据库的数据格式是不是字符串
如果不是，再查一下 java 查询的时候是不是当字符串传进去的 |
|
8
arect OP |
|
9
newaccount 2024-12-06 17:03:47 +08:00
@newaccount #7 看起来是按照字符串排序导致的，但具体是哪里就得摸查一下了
|
|
10
arect OP @newaccount #7 可惜我只是异地部门的小员工，看不了。
|
 |
11
sngxx 2024-12-06 17:07:00 +08:00
没有日志吗
|
|
12
luciankaltz 2024-12-06 17:09:55 +08:00
@inspiration2030 #8 那就要看是业务逻辑处理返回的时候有问题（比如上面说的 js/后端 java 处理格式之类的），还是数据库本身的返回结果有问题了。都不是没可能，谁知道底下代码是怎么写的（
都无从猜起（ |
|
13
arect OP @luciankaltz #12 哈哈哈，就是因为无从下手，所以一个人想了半天想不出。
|
 |
15
eInKLX6Kh6sS3wyc 2024-12-06 17:50:27 +08:00
int/long 越界？
|
 |
16
cowcomic 2024-12-06 17:58:28 +08:00  1
首先通过测试不断的确定到底什么参数能精确返回或精确不返回这个值，二分法不断分割
另外考虑上下界的问题 比如：7200000~7300000 这个查不出来，7199999~7300000 这个呢？ 只要不是偶现问题，通过这种方法一定能找到一个确定的边界，要么进入这个边界就能查出来，要么就是进入这个边界一定查不出来 等确定好这个边界，才好推测 |
|
17
eInKLX6Kh6sS3wyc 2024-12-06 18:00:13 +08:00
float 越界了
|
 |
18
COW 2024-12-06 19:10:26 +08:00 via Android
分布式数据库？
|
 |
19
orioleq 2024-12-06 19:39:21 +08:00 via iPhone
神奇的 bug 就别拿上来说浪费大家时间了，谁知道是不是压根后端筛选的字段就跟前端不是同一个。比如说后端 filter 的数字其实是另一个税后栏位本来就是小于 7200000 的。
自己看吧，解决了再发上来给我们乐乐。 |
 |
20
spritecn 2024-12-07 09:17:42 +08:00
可能有一个用于快速查询的百万位缓存(数据库或缓存),这个位存的时候没有进位,但是查询的时候值被进位了
如果你们订单都是百万级别的话,这个想法还是好的,但入库/查询没对齐,测试还没复现 虽然这么做个人觉得收益不大 |
 |
21
kneo 2024-12-07 17:51:19 +08:00 via Android
看下后端实际执行的 quey 是什么，基本上就能定位问题了。
|
Select Language