merge卡顿或内存爆掉，八成因how/onn设置不当：how='outer'配无索引字符串主键会触发笛卡尔积；on列类型不一致导致逐行比对。应统一dtype、优用how='inner'、去重建索引、处理空值，并用indicator=true诊断匹配异常。
merge 时卡住或内存爆掉，先看 how 和 on 是否合理
大表 merge 卡顿，八成不是 Pandas 慢，而是你让 Pandas 做了不该做的事。比如 how='outer' 配合没索引的字符串主键，会触发全量笛卡尔积式比对；又或者 on 指定的列在两边类型不一致（一边是 object，一边是 string），Pandas 会默默转成 object 再逐行比对，速度断崖下跌。
实操建议：
- 确认两边主键列类型完全一致：
df1['id'].dtype == df2['id'].dtype，不一致就用astype()统一，别信“看起来一样” - 优先用
how='inner'，它只保留交集，数据量天然可控；真要outer或left，确保至少一边主键已去重且有索引 - 如果主键含空值，
merge默认把NaN当作相等来匹配，结果可能多出意料之外的行——提前用fillna()或过滤掉再 merge
用 indicator=True 快速定位连接结果异常
合并后行数暴涨或暴跌，但看不出哪来的，靠肉眼数 len(df1)、len(df2)、len(merged) 没用。这时候 indicator=True 是最轻量的诊断开关，它会在结果里加一列 _merge，值为 both / left_only / right_only，一眼看出哪些行没匹配上。
实操建议：
- 上线前跑一次带
indicator=True的测试 merge，用value_counts('_merge')看分布，尤其警惕right_only远多于预期——说明右边主键在左边根本不存在，可能是上游数据断流或清洗漏了 - 不要长期保留
_merge列，后续计算前用drop(columns='_merge')清掉，避免干扰下游逻辑 - 如果发现大量
left_only，别急着删数据，先查df1[~df1['key'].isin(df2['key'])]抽样几条，看是格式问题（如空格、大小写）、还是业务逻辑本就不该存在
merge 比 concat + 手动对齐快，但前提是主键干净
有人试过先 concat 再用 groupby 聚合模拟 join，结果更慢还容易出错。merge 的底层是哈希连接或排序合并，只要主键列满足条件，它就是最优解。但“前提”很关键：主键不能有重复、不能有不可哈希类型（如嵌套 list/dict）、不能全是 NaN。
实操建议：
- 检查重复主键：
df1.duplicated(subset='key').sum()，非零就得处理——要么去重（明确策略：留 first 还是 last），要么报错中断流程 - 避免用 list、dict、set 做主键列，Pandas 会退化到逐行比对，速度归零；必须用的话，先转成
frozenset或 JSON 字符串 - 如果主键列只有几个唯一值但百万行，merge 反而不如先
set_index('key')再用map或join，因为 merge 的哈希构建成本变高了
内存不够？试试 chunksize + merge 分批，但别无脑切
单次 merge 报 MemoryError，不代表必须换 Dask 或 Spark。Pandas 本身支持分批读取，但 merge 不能直接分批——得自己控制左表分块、右表全量（或也分块）做局部 join，再拼起来。
实操建议：
- 右表小（pd.read_csv(..., chunksize=50000) 分批读左表，每批和右表 merge，用
pd.concat([...], ignore_index=True)累加，内存峰值可控 - 两边都大：按主键哈希分桶，比如
df1['key'] % 100得到 0–99 的桶号，分别保存两表各桶数据到临时文件，再逐对 merge，最后 concat；注意桶内去重和跨桶无遗漏 - 别用
skiprows+nrows手动切片，容易切歪主键分布，导致某批 merge 结果为空或重复
df1.merge(df2, on='key', how='inner', validate='one_to_one') 加一层校验，哪怕只在开发环境跑一次。
