使用GROUPBY的小伙伴需要注意了，这个BUG一定要知道！

GROUPBY函数上线已经有一年了，在处理分组聚合统计需求非常好用，特别是WPS对函数进行了特殊的优化，计算大量数据时速度非常快。

昨天有个数据处理的需求，数据源字段为订单号和购买商品，需要找出一个订单号购买了多种不同商品的订单，这是一个非常简单的需求，虽然数据源行数有些多（40万行），但是使用GROUPBY函数很快就出了结果。

下一步使用XLOOKUP函数将汇总的结果匹配到了数据源，然后筛选大于1的即可。

不出意外的话，事情到这里就结束，完工交差。

然而，出意外了。。。

在筛选大于1的时候，居然发现了错误值#N/A！！！

对于出现的NA我有点诧异，正常来说XLOOKUP的数据是当前数据源汇总出来，是不可能出现NA，现在我还没意识到问题的严重性，以为是自己写错了公式，检查公式没问题，难道是计算未完成导致的？按F9重算工作表还有一样，最后保存文件关闭重启WPS打开表格还是有NA。

到这里我开始有点怀疑GROUPBY函数，使用UNIQUE函数对订单号去重复，果然发现了问题，GROUPBY函数的汇总结果丢了数据。

这是GROUPBY函数返回的【199967】行数据。

这是使用UNIQUE函数返回的【199971】行数据。

注：截图数据是使用RANDARRAY函数生成的随机数据，并非实际数据！

找到原因就好办了，使用透视表可以非重复计数，或者对两列去重复项后 ，使用COUNTIFS函数计数，或透视表计算，筛选大于1即可。

换了种方法处理好数据后，去找了WPS的研发大佬，反馈了这个问题，大佬说是计算hash时发生冲突了，导致分类数量不对，会尽快修改。

同时除GROUPBY函数外，PIVOTBY函数也有相同的问题，当前数据源行数过万时（我测试一些数据，大于5万行数据才会触发这个BUG）导致汇总结果出错。

所以在未来一段时间内，如果小伙伴们需要使用GROUPBY、PIVOTBY函数，需要对函数返回的结果进行验证核对，核对方法有两种。

一、使用VLOOKUP、XLOOKUP、MATCH函数在数据源反向匹配GROUPBY函数返回结果，看是否有NA。

二。使用UNIQUE函数去重复后和GROUPBY函数结果对比看行数是否相同。

最后我会一直关注这个问题，直到WPS修复了这个BUG我再来通知大家，然后大家就可以安心的使用这个函数了~