用pandas.read_csv避免oom需分块读取（chunksize）、精简数据类型（如category/int32）、跳过无用列（usecols）、关闭自动索引（index_col=false）；频次统计优先groupby().size()配合分块，慎用value_counts；避免多次pd.concat，改用预存结果后单次合并；超大数据可哈希分桶落盘或用sqlite3临时聚合。
用 pandas.read_csv 时怎么避免 OOM？
读大文件直接 read_csv 常常一跑就爆内存，不是数据真有那么大，而是默认参数把整张表全塞进内存还建了冗余索引。关键在分块 + 类型精简。
- 加
chunksize参数，比如chunksize=50000，返回的是可迭代的TextFileReader，逐块处理，不累积 - 用
dtype显式指定列类型：'category'替代重复字符串，'int32'或'float32'替代默认的int64/float64 - 跳过不用的列：加
usecols，比如只统计销量，就别读用户地址、备注这些字段 - 关闭索引自动构建：
index_col=False，除非你真要用它做 merge 或 groupby
统计聚合该用 groupby 还是 value_counts？
value_counts 看似方便，但底层会先构建完整 Series 再去重计数，对超长列（如百亿级日志 ID）极易撑爆内存。而 groupby(...).size() 可配合 chunksize 流式累加。
- 单列频次统计优先用
df[col].value_counts(dropna=False)，但前提是这列能放进内存；否则改用分块 +collections.Counter手动合并 - 多列组合统计必须走
groupby，且要加as_index=False避免生成高维索引对象 - 如果只是求和/均值等简单聚合，考虑用
agg指定函数，比先groupby再调用方法更省内存（减少中间 DataFrame 构建）
为什么 pd.concat 是内存杀手？
很多人习惯把每块结果 append 到 list，最后一次性 pd.concat，这会导致 N 次内存拷贝：每 concat 一次，Python 就新建一个更大 DataFrame，旧的还没被 GC 掉。
- 改用预分配 list 存每块的聚合结果（比如每个 chunk 返回一行
pd.Series），最后只 concat 一次 - 更稳的做法：用
functools.reduce+pd.DataFrame.add（适用于相同结构的汇总表） - 实在要拼接，确保所有 chunk 的 dtypes 一致，否则
concat会隐式升格（比如 int32 → int64），悄悄吃掉更多内存
磁盘临时聚合：当内存连单块都扛不住时
有些场景，比如上百 GB 日志按 IP 统计访问次数，连一块 chunksize=100000 的 value_counts 都会 OOM——这时候得把中间状态落地。
立即学习“Python免费学习笔记（深入）”；
- 用
hashlib.md5对 key 做哈希取模，拆成多个临时文件（比如 100 个tmp_00.csv~tmp_99.csv），每块只写对应桶 - 各临时文件分别
read_csv+groupby，再合并结果 - Python 标准库
sqlite3也能扛住：建内存数据库或小文件 DB，用INSERT OR REPLACE累加计数，比 pandas 更低开销
真实项目里最常被忽略的，是列类型没提前压缩、chunksize 设得太大、以及以为 del df 就能立刻释放内存——其实得配合 gc.collect()，而且 pandas 底层的内存池不一定交还给系统。
