pd.merge()爆内存主因是默认全载入内存并笛卡尔匹配，峰值达原始数据2–4倍；须先用usecols选列、dtype压缩（如int32/category）、key列设index，大表改用分块join/SQL/dask，merge后及时del和gc.collect()。
pd.merge() 为什么一跑就爆内存？
不是 merge 本身错，是它默认把左右两个 DataFrame 全加载进内存再做笛卡尔式匹配。哪怕你只 merge 两列，pandas 也会为每行构建临时索引、对齐、填充 NaN——这会让内存峰值飙升到原始数据总和的 2–4 倍。尤其当其中一张表有高基数字符串列（比如日志里的 user_agent 或 url），object 类型会吃掉大量指针内存，根本撑不住。
合并前必须做的三件事
别急着写 pd.merge()，先砍掉内存隐患：
-
usecols只读取 merge 实际用到的列，比如pd.read_csv('a.csv', usecols=['id', 'name']) -
dtype强制压缩：数值列用'int32'/'float32'；重复字符串列（如状态码、地区名）一律转'category' - 对 key 列提前去重并设为 index：如果左表
left_df.set_index('user_id', drop=False)，右表也同理，后续 merge 会跳过内部重建索引步骤
大表合并不能用 pd.merge() 直接硬刚
当任一表 >500MB 或 key 列唯一值 >100 万时，pd.merge() 极大概率 OOM。替代方案按场景选：
- 流式 join：用
chunksize分块读左表，每块只 merge 右表的子集（需右表能按 key 切片，例如用right_df.query("user_id in @chunk['user_id'].unique()")） - SQL 方式：把两张表写入 SQLite 或 PostgreSQL，用原生 JOIN（
pd.read_sql("SELECT * FROM a JOIN b ON a.id = b.id", conn)），数据库引擎自己管内存 - 外存计算：改用
dask.dataframe，它把 merge 拆成图任务调度，不全载入内存，但注意dask启动开销大，小数据反而更慢
merge 后立刻释放中间变量
很多人 merge 完忘了删源表，导致三份数据（left、right、result）同时驻留内存：
立即学习“Python免费学习笔记（深入）”；
- 写完
result = pd.merge(left, right, ...)后，立刻del left, right - 如果 result 还要继续处理，加
gc.collect()强制回收（尤其 Windows 下 CPython 的 GC 不够激进） - 避免链式操作：不要写
pd.merge(a, b).merge(c).drop(...)，每步都生成新对象，中间结果全堆在内存里
真正卡住人的从来不是 merge 这个动作，而是你没意识到 pandas 在背后默默复制了多少份数据——尤其是字符串列和未设 dtype 的数值列，它们才是内存杀手。
