Pandas在千万级数据上变慢，罪魁祸首其实是内存设计上的几个"硬伤"：全量加载、隐式拷贝、单线程执行，再加上中间结果膨胀。而Polars凭借列式存储、延迟执行和类型优化，能把这些短板一一补齐，性能提升立竿见影。
为什么Pandas在千万级数据上会变慢
Pandas的默认行为是把整个DataFrame一股脑儿全塞进内存，而且做计算时还动不动就来个隐式拷贝——比如df[condition]、df.groupby().apply()这些操作。一旦数据量超过物理内存的60%，系统就会频繁触发swap，IO飙升，CPU利用率反而掉下去。这不是代码写得不好，是设计使然——Pandas骨子里就是为"分析友好"设计的，而不是"规模友好"。
- 千万行×百列的CSV，用
pandas.read_csv()加载后，实际内存占用往往是原始文件的3–5倍（字符串列没转category、数值列没设dtype、索引冗余） groupby().agg()这类操作在Pandas里是单线程执行，哪怕你机器有32核，它也只用1个- 链式操作，比如
df.query().sort_values().drop_duplicates()，会产生多个中间DataFrame，内存峰值可能达到最终结果的4倍
用Polars替代Pandas：不改逻辑，只换引擎
Polars是Rust写的列式引擎，API跟Pandas高度兼容（尤其是pl.DataFrame和pl.Expr），迁移成本极低。关键不是"重写"，而是"重读+微调"。
- 读取阶段就降内存：用
pl.read_csv("data.csv", dtypes={"user_id": pl.UInt32, "amount": pl.Float32})，比Pandas省40%+内存 - 延迟执行（
.lazy()）必须加：所有操作先构图，.collect()才真正执行，避免中间结果落地 - 字符串处理别用
.str.contains()暴力匹配，优先用.str.extract()或.str.split().list.get(0)，后者在Polars里是向量化实现，快5–10倍 - 避免
.to_pandas()回退——除非下游库（比如scikit-learn）强制要求，否则全程用Polars；真要导出，用.write_parquet()比.write_csv()快10倍且体积小70%
示例对比（同数据，同逻辑）：
# Pandas（耗时约8.2s，内存峰值4.1GB）
df = pd.read_csv("orders.csv")
result = df[df["status"] == "paid"].groupby("user_id")["amount"].sum().reset_index()
# Polars（耗时约1.3s，内存峰值1.2GB）
df = pl.read_csv("orders.csv").lazy()
result = df.filter(pl.col("status") == "paid").groupby("user_id").agg(pl.sum("amount")).collect()
Dask DataFrame适合什么场景？别硬套
Dask不是"Pandas多线程版"，它是任务调度器+分块引擎。如果你的数据能切分成独立子集（比如按日期分区的订单表），并且计算逻辑支持分而治之（groupby、join、map_partitions），Dask才能真正发挥价值。
- 别用Dask加载单个大CSV：
dask.dataframe.read_csv("data.csv")会自动按行切块，但若块内无法独立计算（比如全局排序、累计求和），后续的shuffle开销会非常大 compute()前务必检查ddf.npartitions：太少（<2）浪费并行，太多（>1000）导致调度延迟压倒计算收益；建议初始设为CPU核心数×2～4- join操作要小心
how="inner"以外的类型：Dask对left/outerjoin需要广播小表，若小表也超百万行，直接OOM - 真需要混用Pandas生态时，用
dask.delayed包装函数比dask.dataframe更可控，尤其涉及第三方库调用
迁移时最容易被忽略的3个细节
pd.Timestamp和pl.Datetime的时区行为不一致：pl.from_pandas()不会自动保留tz-aware信息，必须显式加time_unit="us"和time_zone="UTC"- Polars的
is_null()返回布尔Series，而Pandas的isna()在标量上下文（比如if df["x"].isna().all()）会报错，得改用df["x"].is_null().all() - Dask的
repartition()不是免费的：它触发全量重分布，等价于一次shuffle；如果只是想减少分区数，用ddf.repartition(npartitions=8).persist()比链式repartition().repartition()安全得多
从实际经验来看，90%的"千万级慢"问题靠Polars + .lazy() + 类型精简就能解决；剩下10%涉及跨分区依赖或复杂状态，才需要Dask甚至转向Spark。别一上来就铺分布式，先让单机跑得飞起。
