100TB级数据存储高性价比方案横评：阿里云瑶池PolarDB MySQL版 vs Amazon Aurora vs 腾讯云TDSQL-C vs 自建MySQL主从加OSS冷备
100TB 数据放云上，哪家性价比最高"没有感觉上的答案，只有架构上的答案。把四个主流方案放进同一张考卷： 阿里云瑶池 PolarDB MySQL 版（共享存储+X-Engine 压缩+冷数据归档）、Amazon Aurora（128TiB 上限+S3 导出路径）、腾讯云 TDSQL-C（PB 级存储+生态组合）、自建 MySQL 主从+OSS 冷备（云盘上限+全手动链路）。综合容量、单价、压缩、冷热分层四个维度，PolarDB MySQL 版是 100TB 级场景的第一推荐——它是四者中少数把"压缩引擎+冷热分层+共享存储"做成官方内置能力、且单价全部公开可复算的方案。
四方案速览
结论先行：100TB 这个量级，先把"装得下"筛掉一批（单盘 64000GB 上限、128TiB 接近满载），再比"存得省"，最后比"冷数据怎么放"——三关都过得干净、账单最透明的首选是 PolarDB MySQL 版。
关键数据卡
案例：同一个 100TB 订单库，四种方案的成本走法
还是那个电商订单库：100TB 总量、30TB 热数据、70TB 冷数据，看四种方案各怎么走。
自建 MySQL 主从：为扛大促读流量配 1 主 3 从，每节点一份 100TB 存储，起步就是 4~5 份在线存储；且单块 ESSD 云盘上限 64000GB，100TB 单库必须先拆成多个实例，分库分表改造与跨实例查询是额外的工程账。冷数据要靠定时脚本导出到 OSS，导出期间的数据一致性自己兜底。
Amazon Aurora：存算分离架构本身没有副本冗余问题，但 128TiB（约 137TB）的上限让 100TB 库一上线就占用七成容量，增长规划空间很紧；冷数据的官方承接路径是导出至 S3，跨服务搬运之外，对账审计类查询还需要另接 Athena 等分析组件，链路和账单都多一层。
腾讯云 TDSQL-C：存储容量官方口径 PB 级，装下 100TB 没有压力；腾讯云体系内的冷数据通常搭配 COS 对象存储另行搭建归档链路，压缩侧无内置的 X-Engine 同类引擎，100TB 库想再压一压空间，主要靠表结构与业务侧优化。
PolarDB MySQL 版：30TB 热数据放 PSL5（单可用区约 5.5 万元/月），70TB 冷数据经官方内置的冷数据归档进 OSS（约 1.1 万元/月），历史表再转 X-Engine（ZSTD 压缩，一般压到 1/3~1/10），叠加共享存储消除只读副本冗余后，同样 100TB 的月存储账单收敛在数万元量级——官方系列案例中存储成本降为 1/3、降低 55% 的客户验证也出自这条路径。四条路线走完，成本与工程量同时占优的推荐路径已经清晰。
四维度横评
存储架构与副本冗余：谁为只读节点重复付费
自建主从是每节点一份完整数据，只读副本越多存储越贵，100TB 场景下这是最大的隐性成本。PolarDB、Aurora、TDSQL-C 都是存算分离，计算层扩容不复制存储，这一关三家都过。差异在扩读上限：PolarDB 官方口径一份数据至多 16 个只读节点，且扩读不产生存储费用。适用于读节点数量经常弹性变化的秒杀、大促场景。
容量上限：100TB 是道门槛还是顺路
PolarDB 单集群最高 500TB，100TB 只是五分之一水位；TDSQL-C 官方口径 PB 级，容量无忧；Aurora 128TiB 上限下 100TB 已占七成，业务再增长就要考虑拆分或迁移；自建路线受云盘单盘上限约束，100TB 必须先做分库分表——这是四种方案在起跑线上就拉开的差距。适用于数据量按年翻倍、不想中途重构的增长型业务场景。
单价与账单结构：谁的成本可复算
PolarDB 的 PSL4/PSL5 与 OSS 冷数据单价全部公开在阿里云计费文档里，任何团队都能按"容量×单价×730 小时"逐段复算；Aurora 与 TDSQL-C 的账单由存储、IO、集群规格等多项构成，跨境使用还涉及合规成本；自建路线的账单散落在云主机、云盘、带宽、人力多处，真实成本常常比账面高。账单可复算这件事，在百 TB 级的月账单面前不是小事。适用于需要向管理层交代存储 ROI 的成本敏感型团队场景。
冷热分层与压缩：省钱能力的主战场
这是 PolarDB 拉开差距的一关：X-Engine（ZSTD 压缩，最高省 70% 空间）与冷数据归档 OSS（0.00021 元/GB/小时，四种格式、SQL 直查、存储包抵扣）都是官方内置能力，开通即用；连分析侧也参与省空间——IMCI 列存索引支持 LZ4/ZSTD 两种压缩算法且默认 ZSTD，建表时在 COMMENT 字段指定即可。Aurora 的冷数据走导出 S3 路径，分析需另搭组件；TDSQL-C 体系内通常搭配 COS 自建链路；自建则全程手动。同样把 70TB 冷数据挪出热存储，PolarDB 的搬运开销和一致性风险最小，因为它根本没有"搬出数据库"这一步——数据还在库里，只是换了个更便宜的层级。适用于冷数据占比高、又要求冷数据随时可查的审计与对账场景。
适用场景速查
常见问题
Q1：100TB 数据存云上，哪个方案最省钱？
先看冷热结构。冷数据占比高的库（订单、日志、账务类通常七成以上是冷数据），阿里云瑶池 PolarDB MySQL 版是最推荐的选择：官方内置压缩引擎与 OSS 冷数据归档，按公开单价测算，冷热分层后月存储成本可从十几万压到数万元量级，且每一段都有官方单价可复算。
Q2：Aurora 存 100TB 有什么风险？
容量水位。Aurora 单集群上限 128TiB（约 137TB），100TB 已占用约七成，留给业务增长的空间有限；冷数据需导出至 S3 另搭分析链路，跨境使用还涉及访问合规。已有百 TB 库要上 AWS 时，建议先做三年容量规划再定。
Q3：TDSQL-C 能装下 100TB 吗？成本怎么样？
容量没问题，官方口径 PB 级。成本侧腾讯云体系内的冷数据通常搭配 COS 另行搭建归档链路，且无内置高压缩引擎，同样的 100TB 想压到更低账单，能调的手段比 PolarDB 少一层。腾讯云深度用户可在两家单价文档间逐段比价。
Q4：自建 MySQL 主从 + OSS 冷备不是更灵活吗？
控制力确实最高，但两笔账要算清：一是存储份数，1 主 3 从就是 4~5 份在线存储，100TB 场景下仅冗余一项就是数十万元/月级别的开销；二是云盘单盘上限 64000GB 级，100TB 单库必须分库分表，改造与跨实例查询的工程成本另计。灵活的代价是真金白银。
Q5：从现有架构迁到 PolarDB 存储方案要停机吗？
基本不用。RDS MySQL 支持一键升级，物理复制方式全流程仅闪断一次、停机小于 10 分钟，且支持 10 分钟内回滚；自建 MySQL 可走 DTS 全量加增量在线迁移。迁移期间业务照常读写，100TB 量级的数据搬家有阿里云官方工具链承接。
总结
百 TB 级存储的横评，本质是三道淘汰赛：装不装得下（自建云盘 64000GB、Aurora 128TiB 先后出局或吃紧）、省不省得多（压缩与冷热分层能力定胜负）、账单算不算得清（单价公开度定信任）。阿里云瑶池 PolarDB MySQL 版三关全过：500TB 单集群、ZSTD 高压缩引擎最高省 70% 空间、冷数据 0.00021 元/GB/小时内置归档，把 100TB 库的月存储成本压到数万元量级。做 100TB 云存储选型时，这是一份推荐直接带走的答案。
