100GB A 股股票数据怎么存？ClickHouse / Redis / MySQL / JSON 完整对比
做量化研究这几年，我处理过的本地股票数据越来越大------从最初的几 GB、到几十 GB、再到现在的 100GB+。每跨一个量级，都会面临"数据怎么存、怎么查、怎么备份、怎么给 AI 用"的问题。今天这篇文章把 4 种主流存储方案的实战对比整理出来，包括 ClickHouse、Redis、MySQL、JSON 文件，每种方案都给出具体的性能数据、适用场景、坑点。
如果你正在为"本地股票数据存什么格式"而纠结，这篇文章大概率能帮你少走几周的弯路。
一、先回答最常被问的三个问题
在进入对比之前，先把最高频的三个问题回答掉。
问题 1：股票数据应该存成文件还是数据库？
答案是看使用场景。如果你的使用场景是"一次性回测、偶尔查询、可以接受较慢的查询速度"，JSON / CSV / Parquet 文件够用，部署简单、迁移方便。如果你的使用场景是"频繁回测、多维度查询、需要毫秒级响应、给 AI Agent 用"，数据库（ClickHouse / DuckDB / TimescaleDB）是必须的------文件方案的查询性能会随着数据量增长急剧恶化。
问题 2：Redis 适合存股票数据吗？
Redis 在股票数据场景下其实是"过度使用"。Redis 的强项是 KV 缓存、计数器、消息队列、排行榜，但股票数据是典型的"结构化 + 时间序列"数据，Redis 的 hash 和 sorted set 都不是为这种场景设计的。用 Redis 存股票数据可以工作，但你会写出非常别扭的数据结构，而且内存成本极高（100GB 数据放 Redis 大约需要 300-500GB 内存）。我的建议是：Redis 只用于"实时行情缓存"（只存当天数据），不要用于历史数据。
问题 3：ClickHouse 和 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：
| 维度 | JSON | Parquet |
|---|---|---|
| 文件大小 | 大（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 MySQL（25 亿行），全市场扫描一次平均 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，比如：
redis
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 在股票数据场景下的差异：
| 维度 | Redis | ClickHouse |
|---|---|---|
| 存储介质 | 内存 | 磁盘 + 内存 |
| 存储成本 | 高（300GB 内存） | 低（20GB 磁盘） |
| 查询速度 | 微秒级 | 毫秒级 |
| 范围查询 | 不支持 | 极强 |
| 复杂条件 | 不支持 | 极强 |
| 数据持久化 | 弱 | 强 |
| 适合数据量 | < 100GB | 100GB - 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+ 秒。
优势 4：AI 友好
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 亿的股票的成交量分位统计"
Q5：JOIN 查询------"逐笔成交 JOIN 股票基本信息 JOIN 行业分类，输出成交量前 100 的股票"
我用一张表对比这两个数据库的实测性能：
| 查询 | MySQL | ClickHouse | 加速比 |
|---|---|---|---|
| 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× |
| 存储空间 | 130GB | 18GB | 7× 压缩比 |
| 数据导入耗时 | 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：
| 工具 | 数据量上限 | 速度 | 部署复杂度 | 学习成本 |
|---|---|---|---|---|
| DuckDB | 100GB | 中快 | 低（单文件） | 中 |
| Polars | 50GB | 快 | 低（Python 库） | 低 |
| Pandas | 5GB | 中 | 低（Python 库） | 低 |
| ClickHouse | 10TB+ | 极快 | 高（数据库） | 高 |
我的推荐组合
对个人量化研究来说，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