chunksize参数用于分块读取CSV文件，必须与iterator=True配合使用，返回TextFileReader可迭代器，每次读取指定行数，避免内存溢出；需用for循环或get_chunk()逐块处理，不可直接pd.concat全部块。
chunksize参数在pandas.read_csv中到底起什么作用
chunksize不是“加快读取速度”的银弹，它只是把一次性加载整个文件的行为，改成按固定行数（或近似字节数）分批生成TextFileReader迭代器。真正影响性能的是后续你如何处理每一块——如果对每块都做pd.concat、全量过滤或重复构造DataFrame，反而更慢。
典型误用：df = pd.concat([chunk for chunk in pd.read_csv(..., chunksize=10000)])——这等于又把全部数据拉进内存，还多了一层Python循环开销。
正确思路是：边读边筛、边读边聚合、或只保留需要的字段和行。
如何用chunksize配合条件过滤避免OOM
GB级日志往往只有少量关键行（比如含"ERROR"或特定trace_id），没必要全量解析。用chunksize配合query或布尔索引，在每块内快速丢弃无关数据。
立即学习“Python免费学习笔记（深入）”；
- 优先用
usecols限定只读必要列（如["timestamp", "level", "message"]），减少每块内存占用 - 对每块用
chunk[chunk["level"] == "ERROR"]或chunk.query('level == "ERROR"')，再.append()到结果列表（注意：不是pd.concat在循环里） - 若需去重或聚合（如统计每小时错误数），直接在块内用
groupby+agg，最后再合并各块的聚合结果
示例：
error_counts = []
for chunk in pd.read_csv(log_path, chunksize=50000, usecols=["timestamp", "level"], parse_dates=["timestamp"]):
errors = chunk[chunk["level"] == "ERROR"]
hourly = errors.groupby(errors["timestamp"].dt.hour).size()
error_counts.append(hourly)
result = pd.concat(error_counts).groupby(level=0).sum()
为什么用dtype和date_parser能省下30%+内存
日志中时间字段默认被读成object（字符串），数值字段（如响应码status）若含空值或非数字字符，也会退化为object——这比int32或datetime64[ns]多占3–5倍内存。
必须显式指定：
-
dtype={"status": "Int32", "level": "category"}——"Int32"支持null，"category"对低基数文本列（如"INFO"/"WARN"/"ERROR"）压缩显著 -
parse_dates=["timestamp"]+date_parser=lambda x: pd.to_datetime(x, format="%Y-%m-%d %H:%M:%S")——跳过pandas自动推断，快且省内存 - 避免用
infer_datetime_format=True，它在chunk模式下不稳定，容易报ValueError: Unknown string format
当chunksize设成10万还是OOM，下一步该做什么
说明单块仍超限，或你的处理逻辑本身有内存泄漏（比如在循环里不断append大DataFrame）。这时要跳出pandas.read_csv思维：
- 改用
csv.reader流式读取：逐行解析，用yield返回匹配行，完全绕过DataFrame构造 - 用
dask.dataframe.read_csv替代——它原生支持分块+延迟计算，.compute()前不实际加载 - 预处理切分文件：
split -l 1000000 big.log chunk_，再用glob并行处理多个小文件（注意日志可能跨行，需配合awk保证完整性）
最常被忽略的一点：日志文件本身是否带BOM或混合编码？encoding="utf-8-sig"或encoding="latin1"经常比盲目调大chunksize更有效。
