如何解决导入超大CSV导致的内存耗尽_分片切割与增量导入-phpMyAdmin-PHP中文网

用pandas.read_csv读大文件必炸内存，应加chunksize参数；计数用原生Python按行读；切分CSV需用csvkit或mlr避免引号内换行错误；导入数据库要显式控制事务、防主键冲突；dtype和converters须提前指定以保类型一致。

用 `pandas.read_csv` 直接读大文件必炸内存

它默认把整个 csv 一次性加载进内存，哪怕只是想统计行数或抽样，也会触发 oom。尤其当文件 >2gb 或列数极多（比如日志宽表），read_csv 的解析开销远超数据本身。

实操建议：

永远加 chunksize 参数，让它返回 TextFileReader 迭代器，而不是 DataFrame
避免写 df = pd.read_csv("big.csv") —— 这是绝大多数内存崩掉的起点
如果只是计数，用原生 Python 按行读： sum(1 for line in open("big.csv"))，比 read_csv 快 5–10 倍且内存恒定在几 MB

分片切割不能只靠 `split -l` 粗暴切行

CSV 里换行符可能出现在引号内（如字段含回车），split -l 会把单行数据硬切成两段，后续导入时直接报 ParserError: Expected x fields in line y。

实操建议：

用 csvkit 的 csvcut 或 mlr（Miller）这类懂 CSV 语法的工具切分：mlr --csv --implicit-csv-header cat then head -n 1000000 input.csv > part1.csv
若必须用系统命令，先用 awk 跳过引号内换行：awk -v RS='"[^"]*"' '{gsub(/ /, "\n", RT); printf "%s%s", $0, RT}' input.csv | split -l 1000000（仅限简单引号规则）
切完务必校验首尾行是否完整：用 head -n1 part1.csv 和 tail -n1 part1.csv 看字段数是否一致

增量导入到数据库要防主键冲突和事务膨胀

逐块 to_sql(..., if_exists="append") 看似稳妥，但默认每 chunk 开一个事务，MySQL/PostgreSQL 在高并发写入时容易锁表；SQLite 更是直接卡死。另外，没去重就 append，重复数据会越积越多。

QuickBooks Mileage CSV

使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。

下载

实操建议：

显式控制事务：用 engine.begin() 包住整块插入，而非依赖 pandas 自动 commit
导入前加临时唯一索引或用 ON CONFLICT DO NOTHING（PostgreSQL） / INSERT IGNORE（MySQL）跳过重复
别用 if_exists="replace" —— 它会删表重建，元数据和索引全丢，不是“覆盖”而是“重来”
对 SQLite，把 chunksize 设为 5000–10000，太大反而因 WAL 日志暴涨拖慢

`dtype` 和 `converters` 不设好，分片后类型不一致

不同 chunk 里某列可能前 10 万行全是数字，后 10 万行突然出现空字符串或 "N/A"，read_csv 自动推断类型就会分裂：一部分是 int64，另一部分变成 object，后续 concat 或入库时报 ValueError: invalid literal for int()。

实操建议：

强制指定 dtype：比如 dtype={"user_id": "Int64", "amount": "float32"}（注意用可空的 Int64 而非 int64）
对易脏字段，用 converters 统一清洗：converters={"status": lambda x: x.strip().upper() if isinstance(x, str) else x}
首次读一小块（nrows=10000）跑 df.dtypes 和 df.applymap(type).nunique()，提前发现类型混杂点