嘿，这个问题问到点子上了——处理超大型DataFrame时，内存管理确实是个容易头疼的点！我来一步步给你拆解清楚：

一、del到底做了什么？ #

del df1、del df2并没有直接释放内存，它做的只是删除了df1、df2这两个变量对底层DataFrame对象的引用。

Python的垃圾回收（GC）机制是基于引用计数的：当一个对象的引用计数降到0时，GC才会自动回收它占用的内存。所以如果你的代码里还有其他变量、对象属性或者函数引用指向原来的df1/df2，那即使del了这两个变量，底层数据依然不会被释放。

举个例子：如果之前你写过temp_df = df1，那del df1之后，temp_df还指向原数据，内存就不会被回收。

二、为什么调用gc.collect()还是内存报错？ #

可能有这几个核心原因：

• 隐藏引用没清理干净：Pandas的DataFrame内部可能存在一些你没注意到的引用（比如合并过程中生成的临时视图、索引关联的隐式引用），导致原df1/df2的引用计数没降到0，GC没法回收。
• 合并后的DataFrame本身就占满了内存：合并操作本身会生成一个新的大型DataFrame，这个新df的内存占用可能已经接近甚至超过你的可用内存，就算原df的内存被回收，后续操作依然会触发内存错误。
• Python GC的局限性：虽然gc.collect()会强制触发GC，但对于一些C层面分配的内存（比如NumPy数组的底层内存），有时候GC的回收速度跟不上，或者需要多次调用才能生效。

三、可行的解决方案 #

1. 彻底清理引用 #

先确保没有其他变量指向原df1/df2，然后尝试这套组合拳：

# 先把变量指向None，切断引用
df1 = None
df2 = None
# 再删除变量
del df1, df2
# 强制触发垃圾回收
import gc
gc.collect()

你也可以用sys.getrefcount(df1)查看引用数（注意：getrefcount本身会增加一个引用，所以实际引用数是返回值减1），确认有没有隐藏引用。

2. 合并前先优化内存 #

在合并前就对df1/df2做内存压缩，能大幅降低整体内存占用：

• 将object类型的列转成category类型（如果该列的唯一值不多）：df1['col'] = df1['col'].astype('category')
• 减少数值类型的精度：比如把int64转成int32（如果数值范围允许），float64转成float32
• 清理不必要的列：只保留合并需要的列，比如df1 = df1[['key_col', 'needed_col1', 'needed_col2']]

3. 优化合并方式 #

• 如果合并的键是DataFrame的索引，用df1.join(df2)代替pd.merge(df1, df2)，效率更高、内存占用更少
• 指定merge的how参数（比如how='inner'比outer占用内存少，因为只保留交集）
• 分块合并：如果两个df实在太大，按合并键拆分成分块，逐个合并后再拼接，比如：

# 按key列分块处理
chunk_size = 100000
merged_dfs = []
for i in range(0, len(df1), chunk_size):
    chunk = df1.iloc[i:i+chunk_size]
    merged_chunk = pd.merge(chunk, df2, on='key_col')
    merged_dfs.append(merged_chunk)
final_df = pd.concat(merged_dfs)

4. 检查系统可用内存 #

有时候不是Python的问题，而是你的机器可用内存本身就不足以容纳合并后的DataFrame，这种情况下可能需要升级硬件，或者用分布式计算工具（比如Dask）来处理超大型数据集。

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