pl.scan_csv() 是百亿级数据不崩的起点，因它仅建执行计划、支持谓词下推和流式处理，而 pl.read_csv() 急切加载易致 OOM；显式指定 dtypes、重命名列、哈希分组、避免 lambda 及合理使用 streaming=True 才能发挥 Polars 高性能优势。
pl.scan_csv() 是百亿级数据不崩的起点，不是可选项——用 pl.read_csv() 加载 5GB 以上 CSV，基本等于主动触发 OOM。
为什么 scan_csv 比 read_csv 必须优先用
因为 pl.read_csv() 是急切加载：它会扫描全文件推断 schema、一次性分配内存、把所有行都读进 RAM；而 pl.scan_csv() 只建执行计划，真正读取发生在 .collect() 时，且支持谓词下推（比如 .filter(pl.col("ts") > "2025-01-01") 会直接跳过磁盘上不匹配的块）。
- 百亿行 CSV 文件，
read_csv往往吃掉 200+ GB 内存；scan_csv+collect(streaming=True)稳定在 4–8 GB - 没指定
dtypes？Polars 默认扫描前 10000 行推断类型，对超宽日志文件可能卡住几十秒——必须显式传{"user_id": pl.UInt64, "event_time": pl.Datetime} - 字段名含空格或点号（如
"user.id"），别依赖infer_schema_length，直接用new_columns重命名：pl.scan_csv("log.csv", new_columns=["user_id", "ts", "msg"])
group_by 性能差距真正在哪
不是“Polars 更快”，而是 Pandas 的 groupby().agg() 在默认设置下会强制排序+分块+Python 回调，而 Polars 的 group_by() 默认走哈希分组，且聚合函数编译进 Rust 执行引擎。
huaweicloud-python-sdk-helper
下载
华为云 Python SDK 查询工具。自动发现已安装 SDK 的服务包、Client类、API 方法、入参详情、类信息（__init__ 参数、属性、类型、描述），支持关键字搜索，快速定位目标 API 使用方法。
- 单列字符串分组？先加预哈希：
pl.col("city").hash()，避免每次比较都做 UTF-8 字符串遍历 - 多列分组写成
.group_by(["a", "b"])，别写.group_by(pl.col("a"), pl.col("b"))——后者触发表达式 AST 解析，多一次遍历 -
pl.mean("x")比pl.col("x").mean()快一点，因为少一层表达式包装；但更关键的是：别在agg()里写 Python lambda，会直接报InvalidOperationError: Anonymous function not supported in aggregation
collect() 前必须开 streaming=True 吗
不是“必须”，但对 10GB+ 数据，不开 streaming=True 就等于放弃流式处理优势。普通 .collect() 仍会尝试把整个中间结果塞进内存；而 .collect(streaming=True) 启用分块执行，每块算完立刻释放，峰值内存可控。
- 流式模式下不支持所有操作：比如
.sort()或.unique(maintain_order=True)会退回到非流式路径，触发警告 - 想压内存又需排序？改用
.sort().collect(streaming=True)不行，得拆成两步：.collect(streaming=True)后再用 Pandas 或 DuckDB 接续处理 - 环境变量
POLARS_MAX_THREADS=4比代码里设pl.threadpool_size(4)更稳妥，避免被其他库干扰线程池
scan_csv 和 collect(streaming=True) 是一对绑定动作——漏掉任意一个，就退回 Pandas 式内存模型。 
