PyArrow后端可提速3–6倍，但必须显式指定engine="pyarrow"且满足pandas≥2.0、pyarrow≥12.0，否则静默回退；默认c引擎逐行解析、动态推断类型，导致CPU和GC压力大。
直接换 PyArrow 后端，不改代码结构也能提速 3–6 倍；但不显式指定 engine="pyarrow"，它就根本不会生效。
为什么 pd.read_csv() 默认还是慢？
默认引擎（engine="c"）不是“可开关”的选项，而是硬编码的 fallback 路径。它逐行解析、动态推断类型、频繁构造 Python 对象——尤其遇到混合类型列或缺失值时，CPU 和 GC 压力会陡增。这不是“等一会儿就好”的问题，是底层执行模型决定的瓶颈。
实测 1200 万 × 50 列 CSV：无优化下耗时 ≥90 秒、内存峰值 ≥8GB；换成 PyArrow 后端后，只要参数写对，15 秒内完成、内存压到 ≤3.5GB。
关键点：engine="pyarrow" 必须显式传入，不能靠装了 pyarrow 就自动启用；低于 pyarrow>=12.0.0 会静默退回到 Python 引擎，连警告都不抛。
立即学习“Python免费学习笔记（深入）”；
怎样让 engine="pyarrow" 真正起作用？
- 安装必须满足：
pip install "pandas>=2.0.0" "pyarrow>=12.0.0"—— 版本低一丁点都会 fallback - 单次调用必须带参：
pd.read_csv("data.csv", engine="pyarrow")，不写就是不用 -
dtype和usecols必须提前声明：PyArrow 不做“先读几行猜类型再重读”，它按 schema 流式解析；漏写dtype，它照样走慢路径 - 日期列要用
parse_dates或dtype={"col": "date32[day][pyarrow]"}显式声明，否则遇到非法格式直接抛ArrowInvalid: Unable to parse string
哪些参数组合最常用、最容易踩坑？
以下是最小可行提速组合，覆盖 80% 的生产场景：
pd.read_csv(
"huge_file.csv",
engine="pyarrow",
dtype={"id": "int32", "status": "category", "amount": "float32"},
usecols=["id", "status", "amount", "created_at"],
parse_dates=["created_at"],
low_memory=False # PyArrow 下此参数无效，但保留也不报错
)注意几个易错点：
-
low_memory=False对 PyArrow 无意义，但它不会报错，留着也行；别误以为它能“辅助提速” -
category类型在 PyArrow 后端下行为一致，但必须写成"category"字符串，不能用CategoricalDtype - 如果列名含空格或特殊字符，
usecols必须传原始字符串列表，不能靠names重命名后再选 -
skiprows和nrows在 PyArrow 下支持，但skipfooter不支持，会静默忽略
读 Excel 大文件不能只靠换后端
pd.read_excel() 不支持 engine="pyarrow" 参数，PyArrow 加速目前仅对 CSV/Parquet/Feather 等文本或列存格式生效。处理几百 MB 的 Excel 文件，得换策略：
- 优先转成 Parquet：
pd.read_excel("big.xlsx").to_parquet("big.parquet")，后续全用pd.read_parquet("big.parquet", engine="pyarrow") - 真要读 Excel，用
chunksize+openpyxl底层迭代，避免一次性加载：pd.read_excel("big.xlsx", chunksize=10000) - 别信
convert_float=False这类老参数——PyArrow 下它们无效，还可能干扰类型推断
最常被忽略的一点：PyArrow 加速效果高度依赖你是否愿意花 2 分钟写清楚 dtype 和 usecols。不声明，它就当你是“随便读读”，然后默默退回兼容模式——快不起来，还让你以为是硬件不行。
