太懂这种小文件堆得系统卡爆的感受了——30万+赛事，每个还带好几个CSV和JSON，文件系统找文件都要半天。结合你单机器处理、只会点SQL、还要能手动看数据的需求，给你几个概念层面的方案，都是易上手、适配你场景的：

方案1：优化现有文件夹结构（低成本改进） #

如果不想换工具，先把现有的单层级赛事ID文件夹改成分层分区结构，比如按「年份/月份/赛事ID」来嵌套：

• 示例路径：2023/09/12345/（对应2023年9月的12345号赛事）
• 这样上层文件夹的数量大幅减少，文件系统的索引压力会小很多，遍历和查找速度会明显提升

同时可以做两个小优化：

• 给每个赛事的元数据JSON单独维护一个全局索引文件（比如event_index.json），记录每个赛事的ID、路径、包含的表格类型，遍历计算时先读索引再按需加载对应文件，不用遍历整个文件夹
• 如果同类型表格的结构差异不大，可以给每个表格加一个table_type标识列，把一个赛事下的多个CSV合并成一个文件（比如把赛事基本信息、球员数据、统计数据合并到一个CSV里），进一步减少文件数量

优点：完全兼容现有工作流，不用学新工具，保留手动打开文件夹查看数据的便利性
缺点：本质还是文件系统存储，数据量爆炸式增长时性能提升有限，适合中低速增长的数据集

方案2：轻量级单文件数据库（推荐，适配数据科学场景） #

不用怕数据库复杂，选DuckDB或者SQLite这种单文件、零配置的工具，完全符合你单机器、SQL基础弱的需求：

DuckDB（优先推荐） #

这是专门为数据科学设计的列式数据库，对Python生态（pandas、numpy）无缝集成，语法就是标准SQL，你少量的SQL基础完全够用：

• 可以直接查询文件夹里的CSV：不用导入，直接用SELECT * FROM read_csv_auto('2023/09/*.csv')批量读取某分区的赛事数据，还能按条件过滤，不用全量加载
• 也可以把数据导入成数据库表：一次性把所有赛事数据导入后，就彻底摆脱小文件问题，查询和遍历计算的速度比文件系统快N倍
• 手动查看数据：用DuckDB的CLI工具直接写SQL查询，或者用Python脚本导出某赛事的数据成临时CSV，兼顾便捷性

SQLite #

更偏向传统关系型数据库，适合习惯表结构管理的场景：

• 把每个赛事的固定字段（比如赛事ID、时间、联赛）存在主表，可变结构的表格数据用JSON字段存储（刚好对应你现在的元数据JSON）
• 支持增量写入，每次新增赛事直接插入数据，不用全量加载
• 用SQLite的可视化工具（比如DB Browser for SQLite）可以直接查看数据，上手简单

优点：彻底解决小文件性能问题，支持增量处理，和Python数据科学工具完美配合，手动查看数据的成本低
缺点：需要花1-2小时熟悉基本的数据库操作，但对你的SQL基础来说完全没门槛

方案3：列式存储格式（Parquet/ORC） #

把现有的CSV转换成Parquet（更推荐，Python生态支持更好）这种列式存储格式：

• Parquet压缩比极高，比CSV省70%以上的存储空间，而且支持部分列加载（比如只读取你计算需要的3列，不用加载整个文件），非常适合无法全量加载内存的场景
• 可以按年份/月份分区存储Parquet文件，每个分区下的文件数量远少于原始CSV，文件系统压力大幅降低
• 手动查看：可以用pandas写个10行以内的小脚本，快速导出某赛事的Parquet数据成CSV，或者用Apache Arrow的工具直接查看内容

优点：读取性能碾压CSV，压缩后占用空间小，支持增量更新，单机器处理毫无压力
缺点：手动查看不如CSV直接打开方便，但小脚本可以完美解决这个问题

总结建议 #

如果想快速解决问题、兼顾便捷性和性能，优先选DuckDB：不用改太多现有工作流，上手快，还能直接对接你后续的Python统计分析；如果不想碰数据库，就先优化文件夹结构+转Parquet，成本最低。

内容的提问来源于stack exchange，提问作者hexcoffee