需验证Pandas 2.x新路径是否生效：导入pyarrow.compute并打印版本，再运行merge；若内存增长仍陡峭、CPU未多核并行，则新路径未启用。
PyArrow 后端让字符串 join 不再“拖后腿”
传统 Pandas 的 object 类型字符串列在 merge 时必须逐个哈希、逐个比较 Python 对象——这既慢又占内存。Pandas 2.x 默认启用 Arrow 后端后，字符串自动转为 Arrow 的紧凑二进制表示，join 过程中可直接在连续内存块上做向量化比较，无需构造 Python 对象。
实操建议：
- 确认你用的是 Pandas 2.2+（2024 年起默认启用 Arrow）；检查
pd.options.mode.dtype_backend应为'pyarrow' - 读取 CSV 时显式指定：
pd.read_csv('data.csv', dtype_backend='pyarrow')，避免中间 fallback 到 object - 对已加载的 DataFrame，用
df.astype({'col': 'string[pyarrow]'})强制转换字符串列
merge() 内部不再默认 copy key 列
旧版 Pandas 在 merge 前会隐式调用 .copy() 处理 join key，尤其当 key 是 view（比如切片得到的列）时，极易触发整列复制。Pandas 2.x 改用 Arrow 的 ChunkedArray 模型后，key 列可安全共享内存，只要不修改原始数据，就跳过拷贝。
常见错误现象：
立即学习“Python免费学习笔记（深入）”；
- 合并百万行数据时，
merge耗时突然从 800ms 涨到 3.2s —— 很可能 key 列是df.iloc[:, 0]这类 view，旧版强制 copy，新版默认跳过 - 用
df.loc[:, 'key']替代df['key']也可能意外触发 view，建议统一用df['key']
hash join 实现升级，支持 Arrow 原生 kernel
Pandas 2.x 的 merge 底层调用的是 Arrow 的 compute.hash_join，而非自己维护的 Python/Cython hash 表。这意味着：
- 小表（build side）自动构建 Arrow 的高效 hash table，支持 SIMD 加速字符串哈希
- 大表（probe side）走向量化 probe，一次处理数百行，而不是逐行查表
- 对
category类型列，直接复用其 underlying codes，跳过字符串 decode 步骤
注意：这个加速只在 how='inner' 或 how='left' 且 key 列无 null 时最明显；how='outer' 或含大量 null 时仍需 fallback 到较慢路径。
容易被忽略的兼容性断点
不是所有操作都能自动享受提速。以下情况会 silently 回退到旧逻辑：
- 参与 merge 的任一列 dtype 是
object（哪怕只有一列），整个 join 就降级 - 使用了自定义
suffixes且含非 ASCII 字符（Arrow kernel 当前不支持） - 设置了
validate='one_to_one'等校验参数，会额外遍历两遍数据 - 运行环境没装
pyarrow>=14.0（Pandas 2.x 要求最低版本）
验证是否真走新路径：加一句 import pyarrow.compute as pc; print(pc.__version__)，再跑一次 merge，观察内存增长是否平缓、CPU 是否多核并行 —— 如果还是单核+内存突增，大概率没生效。
