简介面向C#开发者的数据读取优化资源聚焦超大CSV文件的高性能处理以9GB、1.2亿行14列的真实场景为例演示如何在8秒内完成读取与显示。资源为zip压缩包大小约46.39MB共包含49个文件其中11个C#源码文件用于实现核心逻辑sln/csproj工程文件便于直接打开编译exe可执行文件可快速预览效果另附config配置文件、resx/resources资源文件及原始数据包目录结构清晰。已有266人学习下载。资源围绕StreamReader逐行读取、缓冲区大小调节、多线程并行分块等优化手段展开提供可运行示例和完整项目可帮助开发者理解大数据量CSV处理中的内存控制与提速技巧有效避免一次性加载导致的溢出问题为实际项目中的高性能文件解析提供可靠参考。 我最近在梳理一份线上环境的服务日志时碰到了一个特别典型的“特定大数据量的CSV文件读取”问题一个约1.8GB、3200万行的CSVExcel直接打不开Python里一行pd.read_csv()跑了一分多钟还没出结果最终还报了内存错误。这类问题在数据清洗、日志分析和批量导入场景里非常常见踩过坑的人都知道CSV看着简单真要高效读起来里面全是门道。这篇文章我会从底层原理、工具选型、实操调优到问题排查把大数据量CSV读取这件事完整拆一遍给正在被大文件卡住的同学一个可以直接抄作业的方案。1. 先搞清楚大数据量CSV到底难在哪1.1 什么样的CSV才算是“大数据量”很多人对“大数据量”没有概念以为几百MB就很大了。其实从实际工程角度CSV的体量可以从三个维度来看行数Excel 2007之后单表最多104万行超过这个数字Excel打开就只剩一份空壳数据被强制截断。所以严格来说超过100万行的CSV就已经超出“桌面办公”范畴了。体积单个文件500MB以上时普通文本编辑器比如记事本加载就开始卡顿如果超过1GB连SublimeText这种轻量编辑器都可能延迟明显。列数有时候行数只有几万但列有上千列这种宽表同样会撑爆内存因为每多一列底层对象的开销都是指数级增长的。我个人的经验是只要文件大小超过内存的十分之一或者行数超过500万就必须用专门的数据处理方案不能再靠通用工具硬扛。1.2 慢和卡的本质CSV本身是个“裸文本”CSV全称是Comma-Separated Values本质上就是一个纯文本文件。它的读取过程不像读数据库那样有索引、有列统计计算机拿到的是一个字节一个字节的字符流需要自己去做三件事字符解码把字节流按指定编码UTF-8、GBK、ISO-8859-1等解析成可识别的字符串。行与列切割按换行符切行再按逗号或分号切列。这个过程还要处理被引号包裹的字段比如字段里本身包含逗号。类型推断与转换很多时候我们不仅需要“读出来”还要“读成对的类型”。例如123是字符串还是整数2024-01-01是字符串还是日期程序得去猜去试这非常消耗CPU。这三步叠加起来会同时消耗磁盘IO、CPU和内存。尤其第三步类型推断是很多人没意识到的隐形开销。pd.read_csv()默认会对每个字段进行抽样推断类型数据量一大这个步骤比单纯切割文本还慢。所以读“大CSV”不是读一个文件而是做完整个解析管线。2. 工具选型先看场景再选刀2.1 明确你的核心诉求在动手写代码之前先问自己三个问题是需要一次性导入做清洗还是长期查询分析文件是一次性处理还是要反复读你有没有条件使用数据库或专用分析引擎不同答案对应完全不同的方案。我见过太多人拿着大数据集硬怼Excel结果把几GB文件吃进内存又卡死这就是典型的选型错位。2.2 常用方案横向对比下面这张表是这几个方案的真实表现我基于一个1000万行、6列、大小约800MB的CSV文件做过简单测试参数都是默认状态。方案读取耗时占用内存最大瓶颈适用场景Excel直接打开彻底卡死极高行数限制几十万行以内Pythonread_csv()全量读35秒左右约3-4倍文件大小类型推断 全量加载文件能塞进内存Pandas分块读取30秒左右可控制在几百MB迭代处理耗时需要逐批清洗/汇总DuckDBread_csv_auto8秒左右远低于文件大小导入/转换开销SQL分析聚合查询先转Parquet再读首次转15秒之后不到2秒低转换时间同一文件重复读为什么DuckDB这么亮眼因为它不是把整个文件读进内存而是基于向量化执行引擎只读取你查询需要的列和行配合多线程和列式存储的缓存策略天然适合大文件快速探索。如果你的工作目标是“分析”而不是“逐行清洗”DuckDB其实是比Pandas更合适的起点。3. 实操核心用Pandas高效读取大CSV的完整方法3.1 别再用裸的read_csv()读大文件了很多人上来就是df pd.read_csv(large.csv)然后开始怀疑人生。这行代码在大文件场景下几乎等于自杀因为Pandas为了拿到完整的DataFrame必须把全部数据加载到内存同时还得做类型推断。更好的做法是先用少量参数把读取成本压下来。先看一个基础的优化版本import pandas as pd df pd.read_csv( large.csv, encodingutf-8-sig, # 有中文推荐能自动去掉BOM头 low_memoryFalse, # 避免分块类型推断导致混型 dtype{user_id: int32, amount: float32}, # 显式指定类型 usecols[user_id, deal_date, amount], # 只保留需要的列 parse_dates[deal_date], # 日期列单独处理 )这段代码里有两个关键点dtype指定后Pandas不会去“猜”类型省掉大量类型推断时间还顺带把内存降下来。比如把64位类型降为32位内存能直接砍半。usecols是最容易被忽略的优化项。一个300列的文件如果你只需要5列只读5列的时间远小于全量读。因为Pandas底层只解析你选中的列磁盘IO和内存占用都大幅下降。很多情况下仅仅加上usecols和dtype读取时间就能缩短50%以上。我处理那个1.8GB日志时就是用这两个参数让首次读取时间从67秒降到了22秒。3.2 分块读取解决内存不够的唯一正道如果文件在5GB以上或者机器内存只有8GB那上面优化的力度还不够得用“分块读取”的姿势。Pandas的chunksize参数可以让文件按固定行数分批进入内存每次处理一个块最终把结果合并。chunk_iter pd.read_csv( large.csv, encodingutf-8-sig, dtype{user_id: int32, amount: float32}, usecols[user_id, deal_date, amount], parse_dates[deal_date], chunksize500000, # 每50万行处理一次 ) total_amount 0 processed_rows 0 for chunk in chunk_iter: # 只保留本月数据 month_chunk chunk[chunk[deal_date].dt.month 6] total_amount month_chunk[amount].sum() processed_rows len(month_chunk) print(f6月总金额: {total_amount}, 行数: {processed_rows})这一段代码的核心逻辑是每处理一个50万行的块这个块用完后内存就被回收所以无论文件多大内存占用始终保持在一个可控范围内。代价是最终结果是分段聚合如果要做复杂的跨行操作比如排序后取前N行就不太方便了。但应付分组统计、过滤、清洗这类场景分块法足够好。如果你想用分块法做“全量合并”也可以把每个块处理完后写入新的增量数据文件或者直接追加到一个SQLite表里后续再统一查询。3.3 编码问题大数据量CSV里的隐藏炸弹我见过太多人读CSV遇到UnicodeDecodeError然后疯狂加errorsignore结果数据莫名其妙丢了一堆。这里的原则是如果文件里有中文优先试utf-8-sig而不是utf-8因为Windows下生成的CSV经常会带BOM头utf-8会把BOM当成不可见字符塞进第一列列名里。一旦发现gbk或gb18030编码的文件直接用encodinggb18030它是GBK的超集兼容性更好。完全不确定编码的情况下先读一个128KB样本用chardet或charset_normalizer来检测别拿整个文件去猜。from charset_normalizer import from_bytes with open(large.csv, rb) as f: raw f.read(131072) # 128KB result from_bytes(raw).best() print(result.encoding) # 一般能给出正确结论这样能提前定位编码问题避免花费几十分钟读了大半才发现乱码。4. 进阶大招用DuckDB把CSV当数据库表查4.1 为什么DuckDB适合CSV分析DuckDB是一个进程内联的列式分析型数据库不需要安装服务端一个Python包搞定。它读取CSV的策略和Pandas完全不同Pandas默认全量加载DuckDB则是惰性扫描SQL查询需要哪些列就读哪些列。配合SIMD向量化执行几GB的CSV在DuckDB里做聚合查询往往是秒级完成。我在同一条机器上做过对比用Pandasread_csv()全量读入800MB文件再做分组统计总耗时约30秒DuckDB直接查询同一个CSVSQL执行GROUP BY只用8秒而且内存峰值只有Pandas的四分之一。如果你需要反复做多种分析这个差距还会被拉得更大。4.2 DuckDB直接查CSV的三种姿势第一种直接落地成表适合后续多条SQL反复使用。CREATE TABLE deals AS SELECT * FROM read_csv_auto(large.csv, headertrue);第二种不落地每次查询直接扫CSV适合一次性探索。SELECT month(deal_date) AS m, sum(amount) AS total_amount, count(*) AS cnt FROM read_csv_auto(large.csv, headertrue) WHERE deal_date DATE 2024-06-01 GROUP BY month(deal_date) ORDER BY m;第三种在Python里混合使用DuckDB的SQL能力配合Pandas做结果输出。import duckdb duckdb.sql( SUM: SELECT month(deal_date) AS m, sum(amount) AS total_amount, count(*) AS cnt FROM read_csv_auto(large.csv, headertrue) WHERE deal_date DATE 2024-06-01 GROUP BY month(deal_date) ORDER BY m; ).show()这段代码执行完结果以表格形式打印出来数据不会把整个DataFrame塞进内存所以即使你的CSV是10GB只要聚合后的结果小内存就稳得住。4.3 如果同一个文件要反复读先转Parquet另一个我强烈推荐的做法是如果你确定这个CSV会多次使用花一次时间转成Parquet列式格式。Parquet自带压缩信息和列统计读取速度比CSV快一个数量级还能减少存储占用。import pandas as pd chunk_iter pd.read_csv(large.csv, chunksize2000000) first True for chunk in chunk_iter: if first: chunk.to_parquet(large.parquet, enginepyarrow) first False else: chunk.to_parquet(large.parquet, enginepyarrow, appendTrue)后续读取直接pd.read_parquet(large.parquet)速度能提升好几倍。这个方案特别适合那种每天生成一份CSV、每周要做月报的重复性工作。5. 常见问题与排查技巧实录5.1 文件记录段无法读取卡在中间报错这种情况往往出现在文件末尾或者某个不完整的行。可能的原因有三个一是CSV里某个字段包含\r\n换行被某些工具错误切断二是最后一行的末尾缺少换行符三是文件在传输过程中被截断。排查时不要直接读全量用二分法确定大致的坏行位置wc -l large.csv sed -n 1000000,1000010p large.csv逐步缩小范围或者用errorscoerce把坏行转成NaN。如果这都解决不了直接用enginepython再试一次因为C引擎对奇怪引号的处理更严格。值得留意的是Pandas用enginec时如果遇到引号闭合错误会直接抛类似EOF inside string starting at line ...的提示。这个提示本身就是定位器。5.2 读出来全是乱码乱码本质是编码不匹配。文件可能是GBK你用UTF-8去读中文就变成了一堆乱码。最简单的处理是先用5.1节提到的方法检测编码如果是中文环境优先用gb18030如果文件里有BOM用utf-8-sig。还有一类“伪乱码”是文件本身用了latin-1这种在UTF-8下面会显示成“é”这种形状。遇到时可以用encodinglatin-1测试看是否恢复。5.3 Excel打开大CSV卡死甚至崩溃Excel不是给大数据设计的别指望用它开1GB的CSV。宁可把文件拆成多个小文件也不要硬点双击。拆分行数控制在50万行以内列数控制在50列以内Excel基本还能应付。拆行的操作很简单Linux下用splitsplit -l 500000 large.csv chunk_Windows用户可以用Git Bash的相同命令或者用Python分块写出多个文件。5.4 内存溢出 MemoryError内存溢出的解法优先级从低到高依次是操作说明加参数dtype把64位类型降到32位内存直接少一半加参数usecols只读需要的列IO和内存同步下降分块读取控制块大小用完即释放改用DuckDB不把全量数据装进内存先转Parquet列式读取按需加载我个人的建议是如果方法用到第三步还没解决就直接上DuckDB别在Pandas里硬磨了。根据我个人实际操作的经验大数据量CSV读取最核心的思维是做“减法”——减少列、减少类型宽度、减少每次加载的数据量。不要一上来就追求一步到位而是先摸清文件的行数、列数、大小和总行数。我以前吃过亏投影到7000万行的CSV上跑read_csv()结果把16GB内存吃穿整个机器都卡死了。后来我养成一个习惯每次拿到大文件先执行wc -l和head -n 5看一眼结构再决定是用Pandas分块、DuckDB还是直接转Parquet。数据量到了这个级别工具本身决定了上限而选型的前提是先把数据的基本盘摸清。本文还有配套的精品资源点击获取 大数据量CSV高效读取：从Pandas调优到DuckDB与Parquet实战
简介面向C#开发者的数据读取优化资源聚焦超大CSV文件的高性能处理以9GB、1.2亿行14列的真实场景为例演示如何在8秒内完成读取与显示。资源为zip压缩包大小约46.39MB共包含49个文件其中11个C#源码文件用于实现核心逻辑sln/csproj工程文件便于直接打开编译exe可执行文件可快速预览效果另附config配置文件、resx/resources资源文件及原始数据包目录结构清晰。已有266人学习下载。资源围绕StreamReader逐行读取、缓冲区大小调节、多线程并行分块等优化手段展开提供可运行示例和完整项目可帮助开发者理解大数据量CSV处理中的内存控制与提速技巧有效避免一次性加载导致的溢出问题为实际项目中的高性能文件解析提供可靠参考。 我最近在梳理一份线上环境的服务日志时碰到了一个特别典型的“特定大数据量的CSV文件读取”问题一个约1.8GB、3200万行的CSVExcel直接打不开Python里一行pd.read_csv()跑了一分多钟还没出结果最终还报了内存错误。这类问题在数据清洗、日志分析和批量导入场景里非常常见踩过坑的人都知道CSV看着简单真要高效读起来里面全是门道。这篇文章我会从底层原理、工具选型、实操调优到问题排查把大数据量CSV读取这件事完整拆一遍给正在被大文件卡住的同学一个可以直接抄作业的方案。1. 先搞清楚大数据量CSV到底难在哪1.1 什么样的CSV才算是“大数据量”很多人对“大数据量”没有概念以为几百MB就很大了。其实从实际工程角度CSV的体量可以从三个维度来看行数Excel 2007之后单表最多104万行超过这个数字Excel打开就只剩一份空壳数据被强制截断。所以严格来说超过100万行的CSV就已经超出“桌面办公”范畴了。体积单个文件500MB以上时普通文本编辑器比如记事本加载就开始卡顿如果超过1GB连SublimeText这种轻量编辑器都可能延迟明显。列数有时候行数只有几万但列有上千列这种宽表同样会撑爆内存因为每多一列底层对象的开销都是指数级增长的。我个人的经验是只要文件大小超过内存的十分之一或者行数超过500万就必须用专门的数据处理方案不能再靠通用工具硬扛。1.2 慢和卡的本质CSV本身是个“裸文本”CSV全称是Comma-Separated Values本质上就是一个纯文本文件。它的读取过程不像读数据库那样有索引、有列统计计算机拿到的是一个字节一个字节的字符流需要自己去做三件事字符解码把字节流按指定编码UTF-8、GBK、ISO-8859-1等解析成可识别的字符串。行与列切割按换行符切行再按逗号或分号切列。这个过程还要处理被引号包裹的字段比如字段里本身包含逗号。类型推断与转换很多时候我们不仅需要“读出来”还要“读成对的类型”。例如123是字符串还是整数2024-01-01是字符串还是日期程序得去猜去试这非常消耗CPU。这三步叠加起来会同时消耗磁盘IO、CPU和内存。尤其第三步类型推断是很多人没意识到的隐形开销。pd.read_csv()默认会对每个字段进行抽样推断类型数据量一大这个步骤比单纯切割文本还慢。所以读“大CSV”不是读一个文件而是做完整个解析管线。2. 工具选型先看场景再选刀2.1 明确你的核心诉求在动手写代码之前先问自己三个问题是需要一次性导入做清洗还是长期查询分析文件是一次性处理还是要反复读你有没有条件使用数据库或专用分析引擎不同答案对应完全不同的方案。我见过太多人拿着大数据集硬怼Excel结果把几GB文件吃进内存又卡死这就是典型的选型错位。2.2 常用方案横向对比下面这张表是这几个方案的真实表现我基于一个1000万行、6列、大小约800MB的CSV文件做过简单测试参数都是默认状态。方案读取耗时占用内存最大瓶颈适用场景Excel直接打开彻底卡死极高行数限制几十万行以内Pythonread_csv()全量读35秒左右约3-4倍文件大小类型推断 全量加载文件能塞进内存Pandas分块读取30秒左右可控制在几百MB迭代处理耗时需要逐批清洗/汇总DuckDBread_csv_auto8秒左右远低于文件大小导入/转换开销SQL分析聚合查询先转Parquet再读首次转15秒之后不到2秒低转换时间同一文件重复读为什么DuckDB这么亮眼因为它不是把整个文件读进内存而是基于向量化执行引擎只读取你查询需要的列和行配合多线程和列式存储的缓存策略天然适合大文件快速探索。如果你的工作目标是“分析”而不是“逐行清洗”DuckDB其实是比Pandas更合适的起点。3. 实操核心用Pandas高效读取大CSV的完整方法3.1 别再用裸的read_csv()读大文件了很多人上来就是df pd.read_csv(large.csv)然后开始怀疑人生。这行代码在大文件场景下几乎等于自杀因为Pandas为了拿到完整的DataFrame必须把全部数据加载到内存同时还得做类型推断。更好的做法是先用少量参数把读取成本压下来。先看一个基础的优化版本import pandas as pd df pd.read_csv( large.csv, encodingutf-8-sig, # 有中文推荐能自动去掉BOM头 low_memoryFalse, # 避免分块类型推断导致混型 dtype{user_id: int32, amount: float32}, # 显式指定类型 usecols[user_id, deal_date, amount], # 只保留需要的列 parse_dates[deal_date], # 日期列单独处理 )这段代码里有两个关键点dtype指定后Pandas不会去“猜”类型省掉大量类型推断时间还顺带把内存降下来。比如把64位类型降为32位内存能直接砍半。usecols是最容易被忽略的优化项。一个300列的文件如果你只需要5列只读5列的时间远小于全量读。因为Pandas底层只解析你选中的列磁盘IO和内存占用都大幅下降。很多情况下仅仅加上usecols和dtype读取时间就能缩短50%以上。我处理那个1.8GB日志时就是用这两个参数让首次读取时间从67秒降到了22秒。3.2 分块读取解决内存不够的唯一正道如果文件在5GB以上或者机器内存只有8GB那上面优化的力度还不够得用“分块读取”的姿势。Pandas的chunksize参数可以让文件按固定行数分批进入内存每次处理一个块最终把结果合并。chunk_iter pd.read_csv( large.csv, encodingutf-8-sig, dtype{user_id: int32, amount: float32}, usecols[user_id, deal_date, amount], parse_dates[deal_date], chunksize500000, # 每50万行处理一次 ) total_amount 0 processed_rows 0 for chunk in chunk_iter: # 只保留本月数据 month_chunk chunk[chunk[deal_date].dt.month 6] total_amount month_chunk[amount].sum() processed_rows len(month_chunk) print(f6月总金额: {total_amount}, 行数: {processed_rows})这一段代码的核心逻辑是每处理一个50万行的块这个块用完后内存就被回收所以无论文件多大内存占用始终保持在一个可控范围内。代价是最终结果是分段聚合如果要做复杂的跨行操作比如排序后取前N行就不太方便了。但应付分组统计、过滤、清洗这类场景分块法足够好。如果你想用分块法做“全量合并”也可以把每个块处理完后写入新的增量数据文件或者直接追加到一个SQLite表里后续再统一查询。3.3 编码问题大数据量CSV里的隐藏炸弹我见过太多人读CSV遇到UnicodeDecodeError然后疯狂加errorsignore结果数据莫名其妙丢了一堆。这里的原则是如果文件里有中文优先试utf-8-sig而不是utf-8因为Windows下生成的CSV经常会带BOM头utf-8会把BOM当成不可见字符塞进第一列列名里。一旦发现gbk或gb18030编码的文件直接用encodinggb18030它是GBK的超集兼容性更好。完全不确定编码的情况下先读一个128KB样本用chardet或charset_normalizer来检测别拿整个文件去猜。from charset_normalizer import from_bytes with open(large.csv, rb) as f: raw f.read(131072) # 128KB result from_bytes(raw).best() print(result.encoding) # 一般能给出正确结论这样能提前定位编码问题避免花费几十分钟读了大半才发现乱码。4. 进阶大招用DuckDB把CSV当数据库表查4.1 为什么DuckDB适合CSV分析DuckDB是一个进程内联的列式分析型数据库不需要安装服务端一个Python包搞定。它读取CSV的策略和Pandas完全不同Pandas默认全量加载DuckDB则是惰性扫描SQL查询需要哪些列就读哪些列。配合SIMD向量化执行几GB的CSV在DuckDB里做聚合查询往往是秒级完成。我在同一条机器上做过对比用Pandasread_csv()全量读入800MB文件再做分组统计总耗时约30秒DuckDB直接查询同一个CSVSQL执行GROUP BY只用8秒而且内存峰值只有Pandas的四分之一。如果你需要反复做多种分析这个差距还会被拉得更大。4.2 DuckDB直接查CSV的三种姿势第一种直接落地成表适合后续多条SQL反复使用。CREATE TABLE deals AS SELECT * FROM read_csv_auto(large.csv, headertrue);第二种不落地每次查询直接扫CSV适合一次性探索。SELECT month(deal_date) AS m, sum(amount) AS total_amount, count(*) AS cnt FROM read_csv_auto(large.csv, headertrue) WHERE deal_date DATE 2024-06-01 GROUP BY month(deal_date) ORDER BY m;第三种在Python里混合使用DuckDB的SQL能力配合Pandas做结果输出。import duckdb duckdb.sql( SUM: SELECT month(deal_date) AS m, sum(amount) AS total_amount, count(*) AS cnt FROM read_csv_auto(large.csv, headertrue) WHERE deal_date DATE 2024-06-01 GROUP BY month(deal_date) ORDER BY m; ).show()这段代码执行完结果以表格形式打印出来数据不会把整个DataFrame塞进内存所以即使你的CSV是10GB只要聚合后的结果小内存就稳得住。4.3 如果同一个文件要反复读先转Parquet另一个我强烈推荐的做法是如果你确定这个CSV会多次使用花一次时间转成Parquet列式格式。Parquet自带压缩信息和列统计读取速度比CSV快一个数量级还能减少存储占用。import pandas as pd chunk_iter pd.read_csv(large.csv, chunksize2000000) first True for chunk in chunk_iter: if first: chunk.to_parquet(large.parquet, enginepyarrow) first False else: chunk.to_parquet(large.parquet, enginepyarrow, appendTrue)后续读取直接pd.read_parquet(large.parquet)速度能提升好几倍。这个方案特别适合那种每天生成一份CSV、每周要做月报的重复性工作。5. 常见问题与排查技巧实录5.1 文件记录段无法读取卡在中间报错这种情况往往出现在文件末尾或者某个不完整的行。可能的原因有三个一是CSV里某个字段包含\r\n换行被某些工具错误切断二是最后一行的末尾缺少换行符三是文件在传输过程中被截断。排查时不要直接读全量用二分法确定大致的坏行位置wc -l large.csv sed -n 1000000,1000010p large.csv逐步缩小范围或者用errorscoerce把坏行转成NaN。如果这都解决不了直接用enginepython再试一次因为C引擎对奇怪引号的处理更严格。值得留意的是Pandas用enginec时如果遇到引号闭合错误会直接抛类似EOF inside string starting at line ...的提示。这个提示本身就是定位器。5.2 读出来全是乱码乱码本质是编码不匹配。文件可能是GBK你用UTF-8去读中文就变成了一堆乱码。最简单的处理是先用5.1节提到的方法检测编码如果是中文环境优先用gb18030如果文件里有BOM用utf-8-sig。还有一类“伪乱码”是文件本身用了latin-1这种在UTF-8下面会显示成“é”这种形状。遇到时可以用encodinglatin-1测试看是否恢复。5.3 Excel打开大CSV卡死甚至崩溃Excel不是给大数据设计的别指望用它开1GB的CSV。宁可把文件拆成多个小文件也不要硬点双击。拆分行数控制在50万行以内列数控制在50列以内Excel基本还能应付。拆行的操作很简单Linux下用splitsplit -l 500000 large.csv chunk_Windows用户可以用Git Bash的相同命令或者用Python分块写出多个文件。5.4 内存溢出 MemoryError内存溢出的解法优先级从低到高依次是操作说明加参数dtype把64位类型降到32位内存直接少一半加参数usecols只读需要的列IO和内存同步下降分块读取控制块大小用完即释放改用DuckDB不把全量数据装进内存先转Parquet列式读取按需加载我个人的建议是如果方法用到第三步还没解决就直接上DuckDB别在Pandas里硬磨了。根据我个人实际操作的经验大数据量CSV读取最核心的思维是做“减法”——减少列、减少类型宽度、减少每次加载的数据量。不要一上来就追求一步到位而是先摸清文件的行数、列数、大小和总行数。我以前吃过亏投影到7000万行的CSV上跑read_csv()结果把16GB内存吃穿整个机器都卡死了。后来我养成一个习惯每次拿到大文件先执行wc -l和head -n 5看一眼结构再决定是用Pandas分块、DuckDB还是直接转Parquet。数据量到了这个级别工具本身决定了上限而选型的前提是先把数据的基本盘摸清。本文还有配套的精品资源点击获取