我的天

谈Excel，索引肯定是离不开的话题。从经典的lookup到用得很多的vlookup，到index+match，再到vlookup的升级版xlookup，所有的这些都是为了让搜索更方便。xlookup相对vlookup来说的确已经进步了不少，但无论是这些搜索的函数也好，其它按条件汇总的函数也好，总是有一些支持选择列，有一些不支持。之所以有支持和不支持之分，其中一个很重要的原因是支持选择列对写公式的那个人来说很方便，但关键是选择列可能严重影响搜索的性能。感觉上明明很简单的东西却要加载很长一段时间才能出结果，那个加载时间，甚至让你觉得是不可接受的慢，所以在使用这些索引函数的时候，绝大多数的教程都会提醒你数据源得用绝对引用。引用一个确切的范围，即便你把那个范围搞得很宽也行，但是引用一些空白行，又会导致一些意想不到的事情发生，尤其是对某些经典函数来说就会出错。当然，出现这种问题可能是因为我道行不够，如果是高手操作，什么问题都不是问题。

为什么搜索出来的结果可以动态显示，可以显示多行，但是被搜索的内容必须得用绝对引用呢？为什么教程里除了整列选择就没有一些动态确定索引范围的方式呢？隐隐之中我觉得新出现的公式应该可以做到，因为新出的那些高级函数出来的结果都是很动态的。虽然实际上近几年我已经很少关注学习那些新出的东西了，但是我还是有那么一点印象的。

在超级表里面使用公式，引用的单元格不再是经典的单元格名字，而是超级表的列名，前提是你用的那种公式不涉及跨行，如果跨行了，我好像没发现超级表能有什么超级功能，但是如果用超级表的偏移定位函数，的确能实现到达上下行。

xlookup是个比较新的函数，所以它能不能把索引的范围定为超级表的某一列呢？我发现的确是可以这么干的。如果有两个超级表，我要用超级表A作为索引，超级表B的某些数据作为查询条件。那么我在写xlookup公式的时候，我就可以完全用超级表的快捷引用方式。暂时我只尝试过一些比较简单的数据，出来的效果非常好，比我整列引用速度快很多。虽然xlookup是支持整列引用的，但那样的话很慢，而之所以很慢，我估计一个很重要的因素是xlookup只在高级的Excel里面使用，而高级的Excel文件又比低级的Excel文件行数多很多。其实我一直搞不懂为什么同样是Excel的公式，有些函数可以整列引用，有些却不行。有些虽然可以整列引用，但实际上效率不高。用同样的公式，一个引用的是超级表，一个引用的是整列，同样是xlookup，出来的结果就很有差别。如果你在超级表B更新了数据要索引超级表A的内容。引用整列的那个在你把数据粘贴到超级表B的时候，就已经会把你卡得痛不欲生。也正是因为有这种痛不欲生，所以以前当我要引用很多数据的时候，我选择的是用Power Query做一个后台匹配。因为如果用前台做这种整列的索引，整个文件哪怕不是互相影响的那些表，也会变得奇慢无比。在这里我巧妙的地方是利用了超级表的动态性。以前，如果要动态应用可能会增减数据表格内容的时候，好像需要套用offset。

当我要指定某片数据区域的时候，Excel其实是能感知其连片区域范围的，但只是在用公式索引的时候没有给用户一个直截了当的方案而已。

追加查询这种事，2句话搞定，这实在让人太震惊了，但实际上，两句话里其实暗藏了许多玄机，高手用一句话完成了几个步骤的事。能做到这样，绝对是因为对函数这种东西了如指掌。

source = Table.SelectRows(Excel.CurrentWorkbook(), each List.Contains({“表1″,”表2″,”表3”},[Name]))[Content],
result = Table.Combine(source)

Excel.CurrentWorkbook()这种东西通常我们都是后面搭配{[Name=”某表”]}使用，那是点名使用，一次只能一个，但实际很多时候合并工作簿都是里面同型号的表全部合并，如果全部都用这种，得列多长的清单。高手的代码里，还可以把List.Contains变成Text.Contains，如果是list那就是点名要哪些或者不要哪些表，如果是text那就是直接筛选表的关键词，包含哪些关键词或者不包含，各有所长，都能实现。如果命名很规律，那是简单到爆炸的事，即便命名不规律，也能用排除的方式忽略某些不想合并的表。你或许会说，既然是合并工作簿，为什么不直接用从外部文件的工作簿获取呢，那样直接就到位了，选择的时候也很自由，因为那是可以可视化操作的，而且不需要实现把工作簿加入到表，我觉得最根本的区别在于移动文件的时候，外部获取你还得更换数据源，当然了，这个可以通过自动获取数据源地址的方式实现，但直接CurrentWorkbook是最没有烦恼的。要把工作簿里所有表都变成超级表，这在收集和整理表格的时候其实也是有难度的。所以这种一次性用CurrentWorkbook包揽工作簿的方式我觉得最好不要超过10个，3-5个是最合适的。通常，如果用追加合并，可视化系统生成的是Table.Combine{{“AA”,”BB”,”CC”}}类型的多个表格列表，而高手的代码里，source其实就是一个表格的列表。轻描淡写之前，处处暗含玄机。要做到这样得非常清楚每个函数需要什么数据，可以生成什么数据，玩弄的正是表格、列表、记录的互相转换。

同样是contains的功能，list的是后面跟前面对，对上就true，但text是前面跟后面对，对上就true。对我这种初学者来说，这是很迷糊的事，谁先谁后到底是最定义这些公式的，为什么要这么郁闷呢！有这种吐槽大概因为我不熟悉，对高手来说估计是没有疑问的。到底建立这些M函数的时候，他们是怎么分配工作的呢？类似的功能一个人负责？某个统领下的函数一个人负责？最后有没有对“.”以后相同，功能类似东西做比对呢？对我这种懒人来说，类似的函数能用复制粘帖修改就不会用重写这一招，但显然，他们的脑洞估计不是。

看书对照操作是一回事，融会贯通又是另一回事。