Console 命令流式处理百万行 CSV 数据内存优化：命令行实战

xsv真正低内存的流式命令包括：xsv count和headers（几乎零内存）、select和search（恒定内存流式过滤）、slice（无索引时跳行不加载全表，有索引可直接定位）；而sort和table属高内存命令，需慎用。

为什么直接 cat large.csv | head -n 1000 不算流式处理？

它只是截断输出，没做任何解析或转换。真正流式处理的关键是：数据从磁盘读出后，**边解析边传递，不缓存整份结构化结果**。一旦你用 awk、sed 或 xsv 做字段提取或过滤，就进入了流式处理范畴；但若后续接了 sort 或 jq 全量消费输入，就可能打破流式链——尤其 jq 默认会把整个 JSON 数组加载进内存。

xsv 流式命令选哪几个才真低内存？

xsv 是少数真正为超大 CSV 设计的命令行工具，它的内存表现取决于具体子命令：

• xsv count 和 xsv headers：几乎零内存，只扫文件头或逐行计数
• xsv select 和 xsv search：流式过滤，内存恒定（仅当前行+匹配缓冲）
• xsv slice：无索引时仍需跳过前 N 行，但不加载整表；有索引后可直接定位，更快更省
• xsv sort 和 xsv table：高内存命令，sort 必须全量读入才能排序，慎用

实战建议：先 xsv index data.csv，再用 xsv slice data.csv -s 500000 -l 10000 提取中间段，比 tail -n +500000 | head -n 10000 更准（后者会错行，尤其含换行符的字段）。

用 csvsql 或 q 时怎么避免 OOM？

csvsql（来自 csvkit）和 q 都是 SQL 接口查 CSV 的工具，但行为差异很大：

• q 默认流式执行，SELECT * FROM data.csv LIMIT 10 只读前 10 行，内存可控
• csvsql --query "SELECT * FROM stdin LIMIT 10" data.csv 看似一样，但底层会先把整个 CSV 加载为 SQLite 表，百万行就可能吃掉 1GB+ 内存
• 如果必须用 csvsql，加 --no-inference 跳过类型推断，并配合 --max-column-size 限制字段长度，能缓解部分压力

注意：q 不支持嵌套查询或 JOIN 多文件，复杂逻辑仍得靠分步 select + 临时文件。

Python 脚本里调用命令行工具，如何防止管道阻塞？

用 subprocess.Popen 管道组合多个流式命令时，常见卡死不是因为数据大，而是子进程缓冲区满后挂起等待读取——尤其当上游快、下游慢时：

• 永远给 stdout=subprocess.PIPE 配合 stderr=subprocess.STDOUT，避免 stderr 占满缓冲区导致阻塞
• 不要用 .communicate() 一次性收全部输出；改用 iter(proc.stdout.readline, b'') 逐行读取
• 对 xsv select 这类快速命令，可在 Python 中用 os.set_blocking(fd, False) 防止 read() 阻塞，但更稳妥的是用 select.select() 监控可读性

最易被忽略的一点：Windows 下默认管道缓冲区只有 4KB，Linux 是 64KB，跨平台脚本务必显式设置 bufsize=1 或使用 text=True 触发行缓冲。