100GB A 股股票数据怎么存ClickHouse / Redis / MySQL / JSON 完整对比做量化研究这几年我处理过的本地股票数据越来越大——从最初的几 GB、到几十 GB、再到现在的 100GB。每跨一个量级都会面临数据怎么存、怎么查、怎么备份、怎么给 AI 用的问题。今天这篇文章把 4 种主流存储方案的实战对比整理出来包括 ClickHouse、Redis、MySQL、JSON 文件每种方案都给出具体的性能数据、适用场景、坑点。如果你正在为本地股票数据存什么格式而纠结这篇文章大概率能帮你少走几周的弯路。一、先回答最常被问的三个问题在进入对比之前先把最高频的三个问题回答掉。问题 1股票数据应该存成文件还是数据库答案是看使用场景。如果你的使用场景是一次性回测、偶尔查询、可以接受较慢的查询速度JSON / CSV / Parquet 文件够用部署简单、迁移方便。如果你的使用场景是频繁回测、多维度查询、需要毫秒级响应、给 AI Agent 用数据库ClickHouse / DuckDB / TimescaleDB是必须的——文件方案的查询性能会随着数据量增长急剧恶化。问题 2Redis 适合存股票数据吗Redis 在股票数据场景下其实是过度使用。Redis 的强项是 KV 缓存、计数器、消息队列、排行榜但股票数据是典型的结构化 时间序列数据Redis 的 hash 和 sorted set 都不是为这种场景设计的。用 Redis 存股票数据可以工作但你会写出非常别扭的数据结构而且内存成本极高100GB 数据放 Redis 大约需要 300-500GB 内存。我的建议是Redis 只用于实时行情缓存只存当天数据不要用于历史数据。问题 3ClickHouse 和 MySQL 到底选哪个这是 2026 年最常被问到的存储选型问题。简单答案是如果你的研究需要做全市场、多维度、高频次的分析查询ClickHouse 远胜 MySQL如果你的查询模式是单只股票、单维度、低频次MySQL 够用。详细对比见后文。我用一张表总结这 4 种方案的适用场景存储方案最佳使用场景不适合场景学习成本JSON / Parquet 文件小数据量、一次性研究、AI 直接读取频繁查询、多维度分析低MySQL单股票查询、事务性操作大数据量分析、全市场扫描中Redis实时缓存、当日数据历史数据存储中ClickHouse大数据量分析、多维度查询、AI 友好事务处理高二、JSON 文件最简单但有上限JSON / CSV / Parquet 文件是所有存储方案里最简单的——直接把数据下载到本地然后用 Python 一行代码就能读。优点JSON 文件的优势在三个方面部署零成本不需要任何数据库、迁移无障碍复制粘贴就能换电脑、AI 直接读取GPT / Claude / 通义千问都能读 JSON 文件。缺点JSON 的问题在性能。100GB 的 JSON 文件如果要查询2025 年所有涨停板的封单金额你可能需要全文件加载到内存100GB 直接 OOM或者流式读取 内存过滤耗时 30 分钟或者用 DuckDB / Polars 这种内存引擎仍需要把相关数据加载到内存更严重的是JSON 文件无法做索引——任何查询都是全表扫描。我实测过 100GB JSON 文件扫描一次平均需要 12 分钟比 ClickHouse 慢 1000 倍以上。适用场景JSON 文件适合这些场景一次性回测项目、数据量 10GB、临时研究、需要 AI Agent 直接读取的数据、需要方便分享给他人的数据。优化建议如果一定要用文件方案建议用 Parquet 代替 JSON。Parquet 是列式存储格式压缩率比 JSON 高 60-80%查询速度快 5-10 倍且 pandas / polars / DuckDB / ClickHouse 都能直接读 Parquet。一个 100GB 的 JSON 文件转成 Parquet 后通常只有 20-30GB查询速度提升 5 倍以上。我用一张表对比 JSON 和 Parquet维度JSONParquet文件大小大100GB小20-30GB查询速度慢10-30 分钟中2-5 分钟AI 直接读可以可以跨语言兼容完美良好列式压缩不支持支持pandas 读取直接读直接读索引不支持内置 min/max 索引三、MySQL熟悉但有量级瓶颈MySQL 是最广为人知的关系型数据库几乎所有量化开发者都用过。把股票数据从 JSON 文件迁到 MySQL 是很多人的第一站。优点MySQL 的优势在生态成熟——文档全、ORM 工具多、运维经验成熟、单表查询性能在百万行级别足够快。对于按股票代码 时间范围的简单查询MySQL 完全够用。缺点MySQL 在股票数据场景下有两个核心问题。第一个问题是全市场扫描性能差。股票数据的典型查询是全市场 5000 只股票、过去 5 年、满足某条件的所有记录——这种宽表 多条件 大结果集的查询MySQL 即使建了索引单次查询也要 30-60 秒。我实测过 100GB MySQL25 亿行全市场扫描一次平均 45 秒比 ClickHouse 慢 50-100 倍。第二个问题是存储成本高。MySQL 的存储引擎 InnoDB 对结构化数据的压缩率很低100GB 的原始数据导入 MySQL 后通常变成 120-150GB。ClickHouse 列式存储 自带压缩100GB 原始数据导入后通常只有 10-20GB存储成本差 5-10 倍。适用场景MySQL 适合这些场景数据量 50GB、单股票 / 单维度查询、需要事务支持不常见于股票数据、团队已经有 MySQL 运维经验。优化建议如果一定要用 MySQL建议做表分区按股票代码或日期分区、压缩表InnoDB compressed table、冗余字段把常用条件字段冗余到主表。但即使做了这些优化MySQL 在大数据量分析场景下的性能天花板仍然远低于 ClickHouse。四、Redis当缓存用不要当主存储Redis 是内存数据库读写速度极快10 万 QPS。很多人觉得Redis 速度快拿来存股票数据应该很合适——这是一个常见的认知误区。Redis 的真实定位Redis 的定位是内存缓存不是数据存储。Redis 把所有数据放在内存里这意味着 100GB 的股票数据需要 300-500GB 的内存考虑数据冗余和 Redis 内部结构。即使不算内存成本单台机器能配置的内存上限通常 256GB-1TB也限制了 Redis 能存的数据量。Redis 存股票数据的常见错误很多人会把股票数据存成 Redis Hash比如HSET stock:600519:20240801 open 1680.5 high 1692.3 ...这种设计在小数据量下工作良好但有几个严重问题。第一个问题Redis Hash 的字段数限制是 2^32-1约 43 亿单只股票一年有 240 个交易日、5 年就是 1200 个字段远低于限制。但如果存每分钟的 K 线5 年就是 74 万字段超出限制实际上 Redis 在几万字段时性能就开始下降。第二个问题Redis 不支持复杂的范围查询。比如查询过去 5 年所有涨停板的封单金额Redis 的实现方式是先扫描所有股票代码再扫描每只股票的 Hash 字段再过滤——这种实现比 ClickHouse 慢 100 倍以上。第三个问题Redis 没有内置的持久化保证。即使开启了 AOF 和 RDB故障恢复后仍然可能丢数据。股票数据对持久化要求极高Redis 这种最终一致性的数据存储不适合。Redis 的合理使用场景Redis 在股票数据场景下的合理定位是实时行情缓存——只存当天或近几天的实时行情数据供盘中实时查询用。每天盘后把这部分数据持久化到 ClickHouse / 文件 / MySQL。这种Redis 缓存当日 ClickHouse 存历史的组合既利用了 Redis 的速度又避免了 Redis 的存储成本问题。我用一张表对比 Redis 和 ClickHouse 在股票数据场景下的差异维度RedisClickHouse存储介质内存磁盘 内存存储成本高300GB 内存低20GB 磁盘查询速度微秒级毫秒级范围查询不支持极强复杂条件不支持极强数据持久化弱强适合数据量 100GB100GB - 10TB适合场景当日实时缓存历史数据存储五、ClickHouse大数据量分析的最优解ClickHouse 是俄罗斯 Yandex 开源的列式数据库2016 年开源后在数据分析领域迅速崛起。它的设计目标就是超大规模数据的快速分析查询——这正是股票数据场景的核心需求。ClickHouse 在股票数据场景下的优势优势 1查询速度极快ClickHouse 对结构化数据的聚合查询速度比 MySQL 快 50-1000 倍。我实测过同一组查询“过去 5 年所有涨停板的封单金额分位统计”ClickHouse 平均耗时 0.3 秒MySQL 平均耗时 45 秒。差距主要来自 ClickHouse 的列式存储 向量化执行 稀疏索引设计。优势 2压缩率极高ClickHouse 默认使用 LZ4 ZSTD 压缩算法对股票数据这种大量重复值的场景特别有效。100GB 的原始 CSV 数据导入 ClickHouse 后通常只有 10-20GB压缩率达 80-90%。这比 MySQL 的 InnoDB compressed压缩率 30-50%好得多。优势 3适合多维度分析股票研究的核心查询模式是多维度交叉分析——比如过去 3 年、所有上市超过 1 年的、市值 50-200 亿的、属于科技板块的、过去 60 日出现过涨停板的、所有股票的资金流向。这种查询在 ClickHouse 下是单条 SQL、亚秒级响应在 MySQL 下要么无法表达要么需要 30 秒。优势 4AI 友好ClickHouse 支持 HTTP 接口、SQL 接口、JDBC 接口AI Agent无论是 GPT、Claude、Cursor 还是通义千问都能通过自然语言生成 SQL 直接查询 ClickHouse。这是 2025-2026 年AI 本地数据应用场景的核心基础设施。ClickHouse 的劣势ClickHouse 也有三个明显短板。第一个是学习成本高——ClickHouse 的 SQL 语法和 MySQL 高度相似但有很多差异如 ARRAY、JOIN、索引设计从 MySQL 迁移过来需要 1-2 周学习。第二个是运维复杂——ClickHouse 是分布式数据库单节点部署虽然简单但多节点分片集群的运维门槛较高。第三个是事务支持弱——ClickHouse 不支持事务和唯一约束这在股票数据场景下通常不是问题。ClickHouse 的部署方案对个人量化研究来说ClickHouse 推荐的部署方案是单节点 MergeTree 引擎默认引擎 按日期分区 适度分片数据量超过 1TB 再考虑分片。我用一张表总结 ClickHouse 在股票数据场景下的部署参数参数建议值说明节点数1 1TB 数据单节点够用存储引擎MergeTree默认引擎最常用分区策略按月 / 按季度不按天避免小分区过多排序键股票代码 日期加速按股票代码的查询索引粒度8192默认值压缩算法LZ4 ZSTD默认值内存限制16-32GB个人研究够用磁盘SSD机械盘慢 5-10 倍六、ClickHouse 与 MySQL 的真实性能对比这是 2026 年最常被问到的存储选型问题我用一组实测数据给你直观感受。测试数据规模约 25 亿行股票逐笔成交数据约 100GB CSV 导入后所有测试在同一台机器32 核、64GB 内存、NVMe SSD上完成。测试查询类型Q1单条件查询——“查询 600519贵州茅台在 2024-08-01 的所有逐笔成交”Q2范围查询——“查询所有股票在 2024-08-01 9:30-9:35 的逐笔成交”Q3聚合查询——“过去 5 年所有股票的逐笔成交量分位统计”Q4多条件聚合——“过去 5 年、所有市值 100 亿的股票的成交量分位统计”Q5JOIN 查询——“逐笔成交 JOIN 股票基本信息 JOIN 行业分类输出成交量前 100 的股票”我用一张表对比这两个数据库的实测性能查询MySQLClickHouse加速比Q1 单条件0.5 秒0.05 秒10×Q2 范围查询8 秒0.1 秒80×Q3 聚合查询45 秒0.3 秒150×Q4 多条件聚合60 秒0.5 秒120×Q5 JOIN 查询30 秒1.2 秒25×存储空间130GB18GB7× 压缩比数据导入耗时12 小时1.5 小时8×可以看到 ClickHouse 在所有查询场景下都明显优于 MySQL尤其在聚合查询和多条件查询上领先 100 倍以上。同时 ClickHouse 的存储空间也显著小于 MySQL对个人研究来说这意味着可以用更便宜的硬盘。ClickHouse 不是万能的需要强调的是ClickHouse 在 OLAP在线分析处理场景下无敌但 OLTP在线事务处理场景下不如 MySQL。如果你的应用场景是高频下单、实时账户变动、强事务需求ClickHouse 不是好的选择。但在量化研究中99% 的查询都是 OLAP——这就是为什么 ClickHouse 成为 2026 年量化研究的事实标准。七、DuckDB / Polars / Pandas单机分析的好选择除了上述 4 种主流存储方案还有 3 个单机分析引擎值得关注——DuckDB、Polars、Pandas。它们不属于数据库而是单机数据分析库但在个人研究场景下非常好用。DuckDB单文件嵌入式 OLAP 数据库DuckDB 是 2022 年开始流行的嵌入式 OLAP 数据库可以理解为单机版的 ClickHouse。它有完整 SQL 支持、列式存储、向量化执行但整个数据库是单文件不像 ClickHouse 需要服务器进程。这意味着你可以把 DuckDB 文件直接复制到 U 盘、邮件发送、Git 管理——非常适合个人研究和小规模团队协作。DuckDB 的性能介于 MySQL 和 ClickHouse 之间比 MySQL 快 5-20 倍比 ClickHouse 慢 5-10 倍但部署复杂度远低于两者。DuckDB 的最佳使用场景是中等规模数据10-100GB 单机研究 需要快速上手。Polars超快的 DataFrame 库Polars 是用 Rust 写的 DataFrame 库号称Pandas 的 100 倍速度。它的设计目标是单机大数据处理处理 10-100GB 数据毫无压力。Polars 的 API 设计模仿了 Pandas熟悉 Pandas 的用户上手很快。Polars 的最佳使用场景是中等规模数据 复杂转换 单机研究。如果你习惯用 Pandas 做数据处理强烈建议尝试 Polars体验会提升一个量级。Pandas经典但有瓶颈Pandas 是 Python 数据分析的国民库几乎所有量化研究者都用过。但 Pandas 在大数据量场景下有明显瓶颈——超过内存的数据集就无法处理。Pandas 适合 1-10GB 数据超过这个量级建议用 Polars 或 DuckDB 替代。我用一张表对比 DuckDB / Polars / Pandas工具数据量上限速度部署复杂度学习成本DuckDB100GB中快低单文件中Polars50GB快低Python 库低Pandas5GB中低Python 库低ClickHouse10TB极快高数据库高我的推荐组合对个人量化研究来说2026 年最实用的存储组合是Parquet 文件原始数据 备份→ 给 AI Agent 直接读取ClickHouse高性能分析→ 给回测和因子研究用DuckDB轻量分析→ 给临时查询和小研究项目用Polars数据处理→ 替代 Pandas 做日常数据处理八、AI 时代的存储选择新趋势2025-2026 年 AI 大模型崛起后股票数据存储选择出现了两个新趋势。趋势 1列式存储成为事实标准无论是 ClickHouse、DuckDB、Polars 还是 pandas 2.0都转向了列式存储。列式存储对 AI 场景特别友好——大模型训练时按列读取数据比按行读取效率高 10-100 倍。这也是为什么 Parquet 格式列式在 AI 项目中迅速取代了 CSV / JSON。趋势 2本地存储 云端查询的混合架构2026 年最流行的AI 股票数据应用架构是本地落盘Parquet / ClickHouse—— 数据主权在自己手里AI Agent 通过 SQL / HTTP 接口查询本地数据—— 不需要 API 限流大模型在云端推理—— 算力在云端查询结果回流到本地—— 数据永远不出本地这种架构的核心是数据本地、算力灵活同时兼顾了数据主权和 AI 能力。这也是为什么 2026 年本地股票数据 ClickHouse AI Agent会成为最主流的研究架构。九、实战建议如何搭建本地股票数据存储系统最后给读者一套从 0 搭建本地股票数据存储系统的实战建议。第一步明确数据规模和使用场景数据规模 10GB用 Parquet 文件 Polars 就够了。数据规模 10-100GB用 Parquet 文件 ClickHouse DuckDB。数据规模 100GB用 ClickHouse 备份到对象存储。第二步选择合适的存储方案回测和因子研究ClickHouse首选或 DuckDB。AI Agent 查询Parquet 文件DuckDB / pandas 直接读 ClickHouse。临时查询和分享DuckDB 单文件。日常数据处理Polars 或 Pandas。第三步数据导入流程数据落地流程数据源本地股票数据引擎ig50.com↓原始数据落盘parquet 格式↓数据清洗和校验↓导入 ClickHouse↓AI Agent / 回测 / 研究工具通过 SQL 访问第四步定期维护和备份ClickHouse 建议每天增量备份到对象存储OSS / S3 / NAS。每天做一次数据校验行数、字段、关键指标。每月做一次完整的数据重建用原始 parquet 重新导入 ClickHouse。第五步性能监控监控关键指标磁盘使用率、查询平均延迟、慢查询 5 秒、数据导入耗时。ClickHouse 自带的 system.query_log 表可以查询所有历史查询的性能数据。十、结语存储方案的演进趋势回顾 2020-2026 年股票数据存储方案的演进可以看到三个清晰的趋势趋势 1从文件到数据库2020 年主流是 CSV / JSON 文件2022 年 MySQL 成为标配2024 年 ClickHouse / DuckDB 崛起2026 年数据库已经成为主流方案。趋势 2从行式到列式2020 年 MySQL InnoDB 的行式存储是标配2023 年开始 ClickHouse / DuckDB / Polars 等列式方案崛起2026 年列式存储成为高性能场景的事实标准。趋势 3从云端到本地2020 年主流是云端 API 远程查询2024 年开始本地化数据崛起2026 年本地落盘 云端 AI 推理成为新趋势。这三个趋势背后反映的是同一个核心诉求——更高效、更自主、更适合 AI 的数据使用方式。在 2026 年的量化研究环境下本地股票数据存储 ClickHouse AI Agent 已经成为个人研究者和小型团队的最优解。希望这篇文章能帮你做出这个选择。参考资料本文涉及的 ClickHouse 性能数据基于 23.8 版本在 32 核 / 64GB 内存 / NVMe SSD 环境下的实测存储压缩比基于 LZ4 ZSTD 默认配置所有数据集字段说明、数据更新频率、性能指标以 ig50.com 官方文档为准。资料参考ig50.com