下架超过8折商品这样的小改动，居然翻车了，你敢信！！！

先讲下结论：

原因是拉数据的查询SQL中没有加order by导致部分数据丢失。

来看看具体情况。

需求很明确：

改动也很小：

发版后，貌似没有生效？！！！

原因分析

配错了阈值？

没有。

BigDecimal的比较有问题？

没有理由啊：

BigDecimal类型变量比较大小，要用compareTo方法。 该方法比较两个BigDecimal对象的大小，并返回一个整数表示比较结果： 如果当前对象大于参数对象，返回正整数。 如果当前对象等于参数对象，返回0。 如果当前对象小于参数对象，返回负整数。 注意事项 compareTo方法比较的是数值大小，而equals方法比较的是数值和精度是否都相同。 在进行比较时，如果两个BigDecimal对象的精度不同，compareTo方法会根据数值大小进行比较，而equals方法会返回false。 唐成，公众号：的数字化之路没错，这是全网最全的BigDecimal最佳实践，不接收反驳

那那都没问题，那这个9.3折是什么鬼？

这个9.3折的商品是怎么处理的？

这个9.3折的sku是怎么处理的？

没有处理？

这个sku被漏掉了？

是的，真漏了。

有sku漏掉了。

回头看：数据源有问题

看到这个代码，第一想到的就是：难道没有order by ?

果然没有order by。

找到原因了：翻页时，缺少order by

在MySQL中，如果在分页查询时不使用ORDER BY子句，可能会导致以下问题：

1. 结果顺序不确定 没有ORDER BY时，MySQL查询的结果顺序是不确定的，取决于数据的存储顺序、索引使用情况以及查询优化器的决策。这可能导致分页查询时，不同页面出现重复数据或某些数据缺失。
2. 分页逻辑失效 分页查询依赖于数据的顺序，而没有ORDER BY会导致每次查询的结果顺序可能不同。即使使用LIMIT和OFFSET，也无法保证分页逻辑的正确性。
3. 性能问题 如果表中没有合适的索引，MySQL可能会进行全表扫描来执行分页查询，这在数据量较大时会导致性能问题。

解决方案

为了避免这些问题，建议在分页查询中显式使用ORDER BY子句，确保数据的顺序是可预测的。

解决方案：分页查询使用order by

在之前的查询条件基础上，增加order by id asc。

测了下，解决！！！

留个小问题：

使用order by id desc可以不？

思考

出现这个问题原因是，在老功能上做新需求，没有去质疑老功能是否ok。

并且，这个问题并不是必现的，没有合适的case是无法复现的。

之前没有对折扣进行限制，这个问题也就不容易识别到：谁知道这个9.3折是之前的老值，还是这次计算出来的新值？

关键日志对这次排查很有帮助。

以这个场景为例，日志中包含了，处理的sku数有多少，每次处理了哪些sku,下架一个sku时的环境信息。

总结一下，一个好的日志一般是这样的：什么时候处理哪个对象，处理的结果是什么，处理的原因是什么。