Polars 在多数真实业务场景下确实比 Pandas 快，但加速倍数取决于硬件、数据规模、操作类型及是否使用 LazyFrame；8核处理千万行CSV分组聚合时通常快5–10倍。
Polars 在多数真实业务场景下确实比 Pandas 快，但“快多少”不能一概而论——它高度依赖你的硬件（尤其是 vCPU 数量）、数据规模、操作类型，以及你是否用了 Polars 的 LazyFrame。在 8 核机器上处理千万行 CSV 的分组聚合，Polars 常快 5–10 倍；但在单核或小数据（
读取 CSV 时内存和耗时差异极大
Pandas 读 CSV 是“全量加载 + 类型推断 + Python 对象转换”，一个 2.3GB 文件可能瞬间吃掉 7.2GB 内存并卡住；Polars 基于 Arrow 零拷贝，直接映射列式结构，内存峰值通常压到 1/4 以内，且支持 pl.scan_csv() 惰性扫描——连全量加载都跳过。
-
pl.read_csv()仍会加载全部数据，但比pd.read_csv()快 2–4 倍（尤其含字符串列时） -
pl.scan_csv()不加载，只建执行计划，适合预览 schema 或后续接 filter/group_by - 若文件含大量缺失字符串，Pandas 默认转为
objectdtype（每字符串额外 49 字节），Polars 用 Arrow 的large_string或utf8，紧凑得多
分组聚合性能取决于是否启用 Lazy 模式
直接用 pl.DataFrame.groupby().agg()（eager 模式）已比 Pandas 快；但真正拉开差距的是 LazyFrame：它能把 filter、group_by、sort、limit 合并成一次扫描，避免中间结果驻留内存。
- 错误写法：
df.filter(...).group_by(...).agg(...).sort(...).collect()—— 每步都触发计算，浪费并行机会 - 正确写法：
pl.scan_csv(...).filter(...).group_by(...).agg(...).sort(...).collect()—— 整个链被优化为单次多线程扫描 - Pandas 没有等效机制，
query()或loc过滤后必须生成新 DataFrame，内存翻倍风险高
Join 和排序对 CPU 核心数极度敏感
Polars 的哈希 Join 和外部排序默认启用全部可用核心；Pandas 的 merge() 和 sort_values() 始终单线程。这意味着在 4 核机器上，Polars 的 join 耗时可能是 Pandas 的 1/3，但在 AWS Lambda（1 vCPU）上，优势几乎消失，甚至因 Rust 运行时初始化开销略慢。
立即学习“Python免费学习笔记（深入）”；
- Polars 的
join()支持how="anti"、"semi"等 SQL 风格语义，Pandas 需组合isin()或merge()+dropna() - 排序时，
pl.col("x").sort(descending=True)比 Pandas 的df.sort_values("x", ascending=False)更明确，也更易被查询优化器识别为可下推操作 - 注意：Polars 的 join 默认检查 key 类型一致性（如 int64 vs int32），Pandas 会静默转换，容易埋下线上 bug
最容易被忽略的点是“迁移不是 API 替换，而是执行模型切换”：把 pd.read_csv 换成 pl.read_csv 只解决 20% 问题；真正要重写的是整个 pipeline 是否基于 scan_* + collect() 构建。小数据快不快无所谓，大数据慢一秒就是线上延迟——别只测单步，一定要测 end-to-end 完整链路。
