我的天

又花了大半个下午的时间，我把python跨表查询版最后的那个小计功能也开发出来了。其实前一天晚上我已经找到了类似的案例，只要按研究透的那个东西，接着往我自己那里套就可以了。我大概明白里面用到的公式到底是干什么用的，但是把它们套起来了以后，我发现用在我的那里无论如何都不对，所以我就在案例里不断套脚手架，不断地做注视去掉东西。最终发现让我失败的原因是我的那个dataframe是没有索引的，这就让我后面折腾了好长一段时间。

要在dataframe里加小计，首先需要对进行小计的项目进行分组处理。前一天我已经了解过，这样分组出来结果就只是那些聚合的数据。这些聚合的数据如果你不需要带入特殊的分组词，那么你跟原数据合并，然后根据你的分组项目名排序，小计就会合体到原来的dataframe里。如果你要加入小计这样的词语，你就得虚拟新增一列以非分组项目为名称的列名，内容就是小计之类的词。这样的分组结果我不知道为什么那个案例最后要设定以分组项目为索引，因为我在折腾那个案例的时候发现做不做这一步出来的结果没区别。

最最关键，让我折腾半天的根本原因是我要加小计的那个dataframe在从Excel读取数据的时候就已经设定了不添加索引。我发现当我去掉了案例的默认索引以后，和我的脚本出现了同样的问题。所以解决方案是先给我的datafame添加一个默认索引，然后再进行上面说到的分组操作，接着把有默认索引的dataframe跟分组结果结合在一起。同时对分组项目排序。分组后的结果有没有默认索引都无所谓，因为合并时都得重置索引。我没有试过如果这个dataframe也自带了默认索引，最后能不能成功合并。纯粹为了探索，我应该了解这个，但因为我运气好，在研究之前就已经得到了我想要的结果，所以我就没有继续下去，接下来我会继续拿那个案例把玩一下。

为什么会在Excel的单元格数据传入pandas的时候就把默认索引禁止掉呢？其实不禁止也完全没有问题。因为在最后把加工过的东西输出的时候，我可以控制不输出。之所以会有这样的习惯，写出这样的控制，是因为我看的第一本用python批处理Excel的书里面是这么写的。在看那本书的时候，我觉得那本书写得一般般，因为他给出了一个例子，然后大概告诉你要实现什么功能，接着就是展示脚本。我觉得起码你得在介绍那个例子的时候，除了源数据本身，也得展示一下你最终的效果是什么。他们还偶尔说不清具体需求是什么，唯有去研究他们的代码，你才知道原来具体他们要干那个。

在一个明细数据表里加入小计这东西是完全可以实现的，但是从数据处理的角度考虑，为什么我要把明细跟汇总合并在一起呢？如果用我的Excel思维去考虑这个问题，我觉得明细表就是，明细表汇总表用透视表表达出来就好了。因为数据透视表是很灵活的，可以用任意的汇总维度去观察同一个源数据。python可以轻松处理Excel的数据，但是到了Excel以后，展示的方式的控制好像python的插件就有点难以直接控制，而要控制这个最好的方法就是通过api，用VBA控制，因为vba是原生office的自带工具。

我发现python批处理Excel脚本的运行速度跟电脑的CPU有很大关系，跟内存大小关系不大。用我办公室的电脑运行，但需不到6秒，用我宿舍的电脑运行大概需要7秒，用我家里的电脑运行大概需要7.5秒。这是在正常的情况下，如果我的电脑正在执行多任务，这些时间就会说不准了。之所以我说这跟电脑的CPU性能有关，因为运行脚本的时候我盯着任务管理器。发现有段时间Excel的CPU会飙升最大40%，虽然维持的时间很短。不同性能的电脑同样CPU，封顶都会飙到40，这就意味着CPU的核数越多，单核的性能越好，那么这个脚本的运行速度就会越快。6系的i5运行6秒，2系的i3运行8秒，是有差距，但经历过Power Pivot得12秒起，python很爽了。

我觉得这个python脚本还有继续改进的空间，继续努力。

当我终于把功能做出来以后，我却嫌弃出结果太慢了，居然要好几分钟。明明最终我想要的是一个表的合并，为了更快，我不得不拆分为两个查询。第2个查询以第1个查询的结果为基础。其实这么操作，无非我是想利用第1个查询已经得到的缓存结果。那个结果已经被我用表格输出。之前我试过从零开始弄第2个查询，结果发现实在太慢了。如果没有那么多的分组，速度还会那么慢吗？如果只是一个求和，根本无需分组，但问题是，每个批次的东西必须分开计算，然后才可以出现分段的结果。说白了，让我纠结的是一个累计求和。

累计求和这种东西的思路在PQ里通常都意味着新增一列，参数设定匹配某行的某些东西，符合条件就把某列的数据求和。所以实际上这是一个筛选的过程。如果数据很多，筛选肯定会很慢，但除了这样，还能有什么方法吗？据说可以用索引的方法。据说索引的方法比筛选的方法快非常多。如果用python的思路去考虑，我觉得筛选是一个列表的操作，而另外一个是字典的操作。如果不用二分法。历遍列表是非常慢的，但如果要立片字典，历遍是轻而易举的事，而且字典的效率比二分法还要高。所以我应该如何建立索引呢？如果筛选的是多条件，索引大法还能继续管用吗？我觉得现在我遇到的问题那些经常接触数据库的人估计已经纠结过了。这不仅仅是Power Query的问题，这是如何运用数据进行弯曲折叠的问题。只要是数据库，无论是SQL还是其他形式，都会有这种烦恼。

昨天我终于经历了一个Excel要跑好几分钟甚至十几分钟才能出结果的东西，我感觉那没多少数据。我曾经试过把那些东西输出，结果发现输出速度非常慢，每秒钟只处理了不到100个。那些数据粗略计算了一下，可能有超过2万条。为什么加载2万条数据会这么慢呢？这是一个令我纠结的结果，如果把最后的分组都做了，输出的数据只有365条，但如果不做最后的分组，有超过2万条。不做分组的话，那个结果可以在软件里直接展示出来，顶多只需要几秒的运算时间，但是不做分组，把数据输出却有超过2万条，即便我不输出表格只输出数据透视表，依然在输出的时候速度非常慢。为什么对2万条数据进行分组会这么慢呢？除了分组，还有其他快速的方式可以对某条件进行求和吗？整个操作之所以这么慢，除了因为分组，还有排序，还有一些，null转化为0，或者把0转化为null的操作，最后，还有一条我自己都觉得应该会很作死的向下填充。那个结果我花了好几分钟才计算出来，如果让高手去解答，估计运行时间会会是毫秒级的，顶多不会超过三秒钟。

一方面，我很想知道如何提升运行速度，直接拿去问人显然是最显而易见的办法，但在这之前，我想自己先思考一下，毕竟走到这一步已经很不容易，我不想在最后一步认输。这让我想起了高中数学老师的某句经典语录，学习数学几个境界里的最后一句——全而不好（前几句是“不懂不会，会而不对，对而不全”）。