Python DataFrame内存压缩优化方法 适应低内存服务器环境

内存占用虚高，是众多 Pandas 使用者经常遇到的困扰。一张存储着数百万行小整数的 DataFrame，通过 df.info() 查看时，内存消耗却异常庞大，这究竟是什么原因造成的？

核心问题在于 Pandas 默认的数据类型选择策略。它总是优先采用 int64、float64 和 object 来存储数据，即便你存入的是 0 和 1，也照样占用 8 个字节——这显然是一种资源浪费。而 object 列，也就是字符串列，更是典型的“内存大户”，每一个字符串元素都会独立分配一块内存空间，连引用都不共享，内存自然居高不下。你存了 10 个“Yes”，它就会为你分配 10 块彼此独立的内存区域。

为什么 df.info() 显示的内存使用远高于实际数据大小？

直白地说，这就是默认配置带来的问题。Pandas 并非不够智能，而是选择了保守策略——为了确保数据精度不丢失，它倾向使用最安全、最通用的数据类型。例如 int64 占用 8 字节，而 int8 仅需 1 字节，但 Pandas 不会自动帮你完成这种优化，因为它无法预知你的数据范围。因此，遇到内存虚高的情况不必慌张，这是常见现象，关键在于掌握如何为 DataFrame 进行“瘦身”。

如何用 pd.to_numeric() 和 astype() 安全降级数值类型？

很多人习惯直接写 df[col].astype('int32')，结果立刻报错：ValueError: cannot convert float NaN to integer。这就是典型的踩坑——int32 不支持 NaN。如果列中存在缺失值，必须先做处理，或者使用 Pandas 提供的可空整数类型。

正确的做法是：

• 对于数值列，使用 pd.to_numeric(df[col], downcast='integer') 或 downcast='float'，它会自动为你选择最合适的小类型，例如从 int64 降级为 int32，甚至 int16。
• 如果整数列中包含 NaN，那就采用 Int32（注意首字母大写），这是 Pandas 专门为这种情况设计的可空类型：df[col].astype('Int32')。
• 对于浮点列，如果精度可以接受，直接使用 df[col].astype('float32')，内存占用立减一半，而且在大多数场景下，这种精度损失几乎不会产生影响。

字符串列怎么压缩？别只想着 category

astype('category') 确实是一把利器，但使用不当反而会适得其反。它仅对重复值较多的字符串列有效，比如状态码、地区名称这类数据。如果是一列 UUID 或长文本，唯一值数量接近行数，使用 category 反而会占用更多内存，因为需要额外维护一个映射表。

因此，在动手之前，先计算一下唯一值比例：df[col].nunique() / len(df)。如果这个比例很低，比如小于 5%，那么转为 category 效果会很理想；如果比例很高，那就没必要费劲了，可以考虑其他方法。

另外，不要盲目地将所有 object 列批量转换成 category。先用 select_dtypes('object') 筛选出来，再逐列评估。更聪明的做法是从字符串中提取关键信息。例如，如果数据是 "user_123"、"user_456" 这种格式，直接去掉前缀，转为 uint32，效率比保留字符串高得多。

读取阶段就控制内存：用 dtype 和 usecols 参数

等数据加载完成后再进行压缩，其实已经有些晚了，因为内存峰值已经产生。真正低内存的环境，必须在 pd.read_csv() 这一步就开始干预。

• 使用 usecols 参数，只读取你需要的列，避免把冗余字段都加载进来。
• 使用 dtype 参数，在读取时直接指定数据类型，比如 {'user_id': 'uint32', 'status': 'category', 'score': 'float32'}，这样数据一进入内存就是压缩状态。
• 如果是超大 CSV 文件，配合 chunksize 分块处理，每块压缩后再拼接，可以避免一次性加载导致内存溢出。

最后提醒一句：类型选错，比不压缩更糟糕。比如，把可能超出范围的 ID 强制设为 uint16，后续计算会静默溢出，这种 Bug 很难排查。因此，在 downcast 之前，务必核对原始数据的分布范围。