pandas中仅按单字段合并时，列数更多的DataFrame合并耗时更长的原因是什么

对照测试中已经控制了所有和关联计算量相关的变量：

• 主表规模固定为100万行，关联键merge的取值范围固定为0-26，用于匹配的键映射总数完全一致
• 测试时单独运行每轮set_vars后再执行merge，仅统计df.merge()函数本身的运行耗时，完全排除DataFrame初始化构建的时间干扰
• 唯一变量为主表的总列数p，对应的测试代码与耗时结果如下：

  def set_vars(n, p):
      np.random.seed(seed=42)
      df = pd.DataFrame(np.random.randint(27, size=(n,p)), columns=['merge'] + list(range(p-1)))
      df_merge = pd.DataFrame(np.concatenate((np.arange(26).reshape((26,1)), 
                                              np.arange(26).reshape((26,1))), axis=1), columns=['merge', 'val'])
      return df, df_merge
  
  # 5列主表测试
  df, df_merge = set_vars(1000000, 5)
  # %%timeit 结果：255 ms ± 63.2 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
  
  # 20列主表测试
  df, df_merge = set_vars(1000000, 20)
  # %%timeit 结果：494 ms ± 46.1 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
  

最终的异常表现为：同等关联匹配计算量下，主表列数从5增加到20后，merge的总运行耗时接近翻倍。

这种现象不属于实现异常，是pandas merge运行逻辑的必然结果——merge的全流程远不止“键值关联匹配”这一个环节，列数增加带来的额外开销主要来自两个阶段：

• 结果组装阶段的逐列拷贝开销
  哈希关联匹配本身的耗时，仅和关联键的唯一值数量、总数据行数相关，和表中非关联列的数量没有关系。但匹配完成后，pandas需要把主表中所有非关联列的数值，按照匹配后的新行索引顺序，逐列重新拷贝、对齐，最终拼接成完整的结果DataFrame。列数越多，需要逐列拷贝的内存块数量就越多，这部分的耗时和主表列数严格呈线性正相关：20列的表需要拷贝的列数是5列表的4倍，拷贝带来的额外耗时自然会大幅拉长总运行时间。
• 宽表场景下的内存缓存命中率下降
  pandas的数值列按连续内存块存储，列数越多，单表占用的总内存就越大。当数据量超出CPU缓存的可承载容量时，所有后续的内存读写都会出现缓存不命中的情况，需要从慢速主存中加载数据，读写性能会出现明显下降。100万行的5列int数据总内存约20MB，20列同规模数据总内存接近80MB，远超普通桌面CPU的单线程L3缓存容量，这部分额外的内存IO等待时间，也是耗时上升的重要组成部分。

可通过简单对照实验验证上述结论：如果单独提取关联列完成哈希匹配，拿到最终的行索引映射后，再用索引对齐的方式从原宽表中取数组装结果，会发现纯哈希匹配环节的耗时在不同列数下几乎完全一致，所有的额外耗时都来自结果拼装和内存读写阶段。

内容的提问来源于stack exchange，提问作者quentin