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