直接用pandas.read_csv()读千万行卡死，本质是默认C解析器逐行做类型推断和Python对象构造；改用PyArrow后端（engine="pyarrow"）并预设dtype、usecols等参数，可将1200万行读取从90秒降至15秒内、内存从8GB压至≤3.5GB。
为什么直接用 pandas.read_csv() 读千万行会卡死
不是内存爆了就是读取慢到怀疑人生——本质是默认引擎（C parser）在逐行解析时要做大量类型推断、字符串拷贝和 Python 对象构造。尤其当 CSV 包含混合类型列、缺失值、非标准分隔符时，read_csv() 会在每行反复调用 Python 层逻辑，CPU 和 GC 压力陡增。
实测：1200 万行 × 50 列的 CSV，在无 dtype 预设、无 low_memory=False 的情况下，可能占用 8GB+ 内存、耗时 90 秒以上；而同样数据用 PyArrow 后端常压在 15 秒内、峰值内存 ≤3.5GB。
- 别信“加
nrows=1000看头几行”就能预估全量性能——小样本无法暴露类型冲突和内存碎片问题 -
engine='c'是默认值，不能关；想提速必须换后端，不是换 engine - PyArrow 不是插件，是 Pandas 2.0+ 原生支持的执行后端，启用后
read_csv()底层自动走 Arrow C++ 实现
怎样用 PyArrow 后端真正生效
关键不是装 pyarrow，而是让 Pandas 明确知道“这次我要用它”。Pandas 2.0 默认仍走传统路径，必须显式指定 engine='pyarrow' 或设置全局选项。
- 单次读取：直接传参
pd.read_csv("data.csv", engine="pyarrow") - 全局生效（推荐）：
pd.options.io.excel.xlsx.engine = "pyarrow"不起作用——正确写法是pd.options.mode.dtype_backend = "pyarrow"（影响后续 dtype 推断），但读 CSV 还得单独设engine - 必须安装
pyarrow>=12.0.0（Pandas 2.0 要求），低于此版本会 fallback 到 Python engine 并静默警告 - 遇到
ArrowInvalid: Unable to parse string错误？说明某列有非法日期/数字格式，PyArrow 比 Pandas 更严格，需配合dtype或parse_dates预声明
dtype 和列筛选不写清楚，PyArrow 也救不了你
PyArrow 加速的前提是“少做推断”。它不会像 Pandas 那样先读几行猜类型再重读，而是按你给的 schema 一次性流式解析。漏写 dtype，它照样 fallback 到慢路径。
立即学习“Python免费学习笔记（深入）”；
- 数值列一律用
dtype={"col_a": "int64[pyarrow]", "col_b": "float64[pyarrow]"}，注意方括号里的[pyarrow]——这是 Pandas 2.0 的新 dtype 语法，不是字符串 - 字符串列强烈建议用
"string[pyarrow]"，比默认object节省 40%+ 内存且支持向量化操作 - 只读部分列？用
usecols=["id", "name", "amount"]，PyArrow 会跳过磁盘上其他字段，比 Pandas 的列裁剪快得多 - 时间列别依赖
infer_datetime_format=True，PyArrow 不认这个参数；改用parse_dates=["ts"]+date_format="%Y-%m-%d %H:%M:%S"
内存不够时，分块读取必须配 dtype 一致
用 chunksize 分批处理千万级文件很常见，但如果不统一每块的 dtype，Pandas 会把每块当作独立 DataFrame 拼接，导致类型不一致（比如一块是 int64[pyarrow]，另一块是 int32[pyarrow]），最终合并时报 TypeError: incompatible dtypes。
- 先用小样本跑一次
pd.read_csv("sample.csv", engine="pyarrow", dtype=...)确定完整 dtype 字典 - 分块时显式传入同一份
dtype：for chunk in pd.read_csv(..., chunksize=100000, engine="pyarrow", dtype=dtype_dict) - 避免用
pd.concat(chunks)全部载入内存；改用chunk.to_parquet()直接落盘或流式计算（如chunk.groupby(...).sum()后累加） - PyArrow 分块读取不支持
skiprows动态跳过——首块用skiprows=0，后续块用skiprows=n手动算偏移，容易出错；更稳的方式是先用awk或sed切割文件
PyArrow 后端不是银弹：它对格式规整、schema 明确的数据加速显著，但遇到大量空值嵌套 JSON、超长不定长字符串、自定义 quote 字符时，仍可能比 Pandas 的 Python engine 更慢。上线前务必用真实数据集做端到端耗时对比，而不是只看文档里的 benchmark 数字。
