@xiaoni 这个x代表姓名表中的每一个姓名，我的理解是在奖金表转换为的record构成的list的最后插入一个比如[姓名="dq"]（这就是x）的元素，然后找到姓名出现最多的那个元素，每个元素都只出现了一次，因此取最后一个元素[姓名="其他", 奖项="参与奖", 奖金=500]，然后在后面跟一个[姓名="dq"]，也就重新定义了record中的姓名字段，把字段值从"其他"变为了"dq"

跟着几位大神学到了不少，不过还有一个疑问，不知大神们为什么都喜欢用[a=x1,b=x2][b]这样的写法，为什么不用let a=x1, b=x2 in b这样的写法呢，是不是用构造Record效率更高一些呢

@libo5563 大神这个思路很好啊，我想这是模拟Table.NestedJoin的原理吧，不过可以设置匹配不到时返回特定的行，这样就可以省略中间步骤列了，只是不知这样和直接合并查询相比效率如何，会不会慢一些

@deadzlq 这个思路也很好，先在奖金[姓名]中做筛选，返回可做查询依据的MatchCol列，再用这列做查询，不过还有几点疑问：

1. List.FirstN(奖金[姓名],3)是不是没有必要？是不是为了避免有个人就叫“其他”的这种情况？
2. else "其他"不够灵活，如果奖金表中属性值变化了就不行了，比如写为了“其他人”，这条语句就得同时修改，是不是可以优化为else List.Last(奖金[姓名])，但是这样却也限定了其他情况必须放在奖金表的最后一行，否则就不行了，思来想去怎么都没有完美的解决办法
3. 仔细想了想这样其实和我一开始的查询一次展开再替换null也差不多，都是把匹配不上的值做特殊处理，之后都得有二次查询之后再删除中间步骤列的一步，如果用if语句做处理的话，其实可以用好个函数进行判断，包括：
   if List.Contains(奖金[姓名],[姓名])
   if List.PositionOf(奖金[姓名],[姓名],Occurrence.First)<>-1
   if Table.PositionOf(奖金,[姓名=[姓名]],Occurrence.First,"姓名")<>-1

还可以用List.Mode，这样可以省略if判断：
(x)=> List.Mode(List.Combine({{x[姓名]},奖金[姓名]}))
我又试了试List.FirstN、List.LastN、List.RemoveFirstN、List.RemoveLastN、List.Skip等函数，都不行，因为它们都没法设置匹配不到时返回特定值

不知这些方法的效率怎样，哪种方法最好

@飞天篮球 老哥这个脑洞开得有点大啊，你是怎么想到这样做的？我看了一个多小时才看明白是怎么回事，思路够牛，不过这经过“table转record-插入list-找众数-替换field-record转table”这么一顿操作猛如虎，会不会影响效率啊，当数据量大的时候会不会刷新时间过长呢，我还是找个例子试试吧

@飞天篮球 根据大神指点我又试了试，把数据源扩充到10万行，方法1直接写入常量筛选，方法2345的List引用变量，测试结果是速度由快到慢：1>2≈3≈4>5，看起来直接写入常量是最快的，引用变量的话3个List函数速度都差不多，List.Contains略快于其他两个，而递归是最慢的，这和我预想的非常不一样啊 ;-D

经群友提醒，我用Table.Combine(List.Repeat({Table.Buffer(源)},100000))扩充数据量，测试了一下，结果从快到慢是方法2>方法1>方法4>方法3>方法5，这个结果和我设想的不一样啊，看来用递归来设置中断规则的方法并没有像想象中的快，据群友所说可能是因为随着数据量的增大到了一定时候就会堆栈溢出了，只好是不懂学习中……

这个功能PBI应该不擅长吧，我用PBI没有处理过这类问题，感觉PBI还是以处理数据为主，不擅长用来生成数据或是解方程，这类问题用规划求解或VBA应该更合适吧，python没学过，不好说