Python中Pandas如何优化DataFrame内存占用以防OOM？-Python教程-PHP中文网

OOM几乎从来不是pandas本身的问题，而是pd.read_csv()默认全量加载、类型推断和object列滥用导致内存暴涨2–4倍；优化核心是读时控制（chunksize/usecols/dtype/index_col）、读入降级（数值downcast/字符串转category）、计算不累积（groupby.size优于value_counts）。

python中pandas如何优化dataframe内存占用以防oom？

直接说结论：OOM 几乎从来不是 pandas 本身的问题，而是 pd.read_csv() 默认全量加载 + 类型推断 + object 列滥用导致内存暴涨 2–4 倍。优化核心就三件事：读的时候就控住、读进来就降级、算的时候不累积。

pd.read_csv() 加载大文件必设的四个参数

不加任何参数直接读 GB 级 CSV，等于主动申请 OOM。关键不是“能不能读”，而是“要不要把整张表塞进内存再开始干活”。

chunksize：设为 50000 或 100000，返回 TextFileReader 迭代器，一块一块处理，峰值内存可控
usecols：只读真正需要的列，比如统计销量，就别碰 'user_address'、'remark' 这类字段
dtype：显式指定类型，避免 pandas 自动推成 object 或 float64；重复字符串列优先用 'category'，整数列能用 np.int32 就不用 int64
index_col=False：除非真要用索引做 merge 或 groupby，否则关掉自动索引构建，省下额外内存和时间

df.memory_usage(deep=True) 才是真实内存用量

df.info() 默认显示的是浅层估算值，对 object 列严重低估——它只算指针大小（8 字节），不递归算每个字符串实际占多少。真正要诊断，必须加 deep=True：

df.memory_usage(deep=True).sum()  # 返回字节数
df.memory_usage(deep=True).sum() / (1024**3)  # 转 GB，才可信

常见错误现象：sys.getsizeof(df) 返回值比 df.memory_usage(deep=True).sum() 小一个数量级，因为它完全忽略底层 NumPy 数组和字符串对象的实际内存；df.info() 显示 “memory usage: 300.0 MB”，但任务管理器里 Python 进程已吃掉 1.2 GB —— 那多出来的就是 object 列里藏着的字符串本体。

Python Hardener

通过完整的安全审查、代码整洁重构、健壮的错误处理、正确的日志记录以及完整的文档字符串覆盖，强化 Python 脚本。

下载

数值列降级和字符串转 category 的实操边界

不是所有列都适合无脑降级或转 category，踩错会丢数据或变慢。

数值列用 pd.to_numeric(..., downcast='integer') 或 downcast='float' 是安全的，但得确认范围：int32 最大支持 2147483647，超了会静默溢出成负数
字符串列转 category 有效当且仅当唯一值数量 ≪ 总行数（比如 100 万行中只有 12 个省份）；若唯一值 > 行数 50%，反而比 object 更占内存，因为多了编码映射表
convert_dtypes() 看似智能，但它对字符串列默认转成 string（Pandas 新 dtype），不解决内存问题，也不压缩；真想省内存，还是得手动 .astype('category')

groupby().size() 比 value_counts() 更抗 OOM

单列频次统计时，df[col].value_counts() 会先构造完整 Series 再去重计数，中间对象无法流式释放；而 df.groupby(col).size() 可配合 chunksize 分块累加，内存只随唯一值数量线性增长。

分块统计示例：

counts = pd.Series(dtype='uint32')
for chunk in pd.read_csv('log.csv', chunksize=50000, usecols=['ip'], dtype={'ip': 'category'}):
    counts = counts.add(chunk['ip'].value_counts(), fill_value=0)
# 最后 counts 就是全局频次

慎用 pd.concat([chunk.value_counts() for chunk in reader])：每 concat 一次就拷贝一次，N 块 → N 次内存峰值
如果连单块 value_counts() 都撑不住（比如百亿级 ID），就得落地哈希分桶：用 hashlib.md5(key.encode()).hexdigest()[:2] 取前两位做文件名，写到 tmp_00.csv～tmp_ff.csv，再分别聚合

最易被忽略的一点：dtype 不一致会导致 concat 或 groupby 隐式升格——比如 int32 列和 int64 列拼一起，结果全是 int64，悄悄多吃一倍内存。处理前务必统一 dtypes。