企业官网建设流程全解析

把数据库的存储空间算到100TB这个量级，你大概率已经不会再去纠结某个慢SQL要不要加索引了——账单上那一串数字才是每天早上最扎心的东西。我前两年给一个金融类客户做过一次成本复盘，光是历史库就堆到接近90TB，后来迁到PolarDB并持续扩容到100TB以上，存储成本被重新压下来一大截。今天这篇就把100TB当靶子，把PolarDB的存储成本从计费口径到实际测算、再到和RDS/自建MySQL的对比，完整拆一遍。

先说清楚这篇文章能解决什么问题：如果你是一名架构师、DBA，或者是公司里负责审云账单的运维负责人，此刻正在纠结“100TB的数据到底放哪最划算”，那这篇就是给你写的。我会把云数据库的成本结构、PolarDB的省钱原理、真实测算口径、迁移和连接实操全部过一遍，尽量做到你看完能直接套用，自己也能算一遍账。

1. 100TB存储规模下，成本问题的本质是什么

1.1 为什么100TB是一个重要的分水岭

很多人对数据库容量没什么体感，觉得“反正云上可以无限扩，多花钱就行”。但数据量一旦到100TB，很多想法都得变。

先说一个简单的换算：100TB如果按1024进制，就是102400GB。就算云盘每GB每月只收1块钱，裸存储成本也要十万元级别。这个数字直接把问题从“技术选型”顶到了“财务决策”层面。老板一定会问：这笔钱花得值不值？有没有更便宜的办法？这时候你再掏出一堆性能参数，没有任何说服力，得拿出账单来。

再说架构层面。数据量不到50TB时，一个RDS MySQL高可用实例加定期归档，基本能撑住。但到了100TB，单实例的容量上限、备份耗时、恢复时间会接连成为瓶颈。不少团队被逼着走上分库分表的路，拆出几十个实例，结果每个实例都要单独购买计算资源和存储空间，还要配主从复制。存储不仅没有省，反而因为多实例冗余，总成本直线上升。

我见过最夸张的一个案例：某电商团队把订单表按月份拆了36个RDS实例，每个实例1TB到3TB不等，主备双节点加备份空间，月初对账时DBA要同时维护36套监控和备份策略，存储总成本比合并前高了一倍多。这就是存储规模逼近100TB时最典型的“管理成本吞噬资源成本”现象。

而PolarDB这类云原生数据库把存储和计算彻底分开，所有计算节点共享同一份存储数据，存储池对外可以做得很大，内部自动扩展。你要关注的不是拆多少个实例，而是业务到底需要多少计算能力、多少实际存储。这个思维转变，才是成本优化的起点。

1.2 云数据库账单上到底有哪些成本项

说到算账，很多人第一反应是看“存储单价”，但云数据库的真实账单是一个组合体。以PolarDB为例，一个集群的月度成本通常包含这几块：

• 计算节点费用：主节点（RW）和只读节点（RO）各按规格计费，比如4核16GB、8核32GB，不同规格价格不同。
• 存储空间费用：按集群实际占用的存储容量计费，支持自动扩容，单位一般是“元/GB/小时”。
• 备份空间费用：数据库备份文件占用的对象存储空间，超过免费额度后单独计费。
• 网络流量费用：公网访问产生的下行流量按GB计费，内网流量免费。
• 增值功能费用：SQL洞察、性能洞察、安全审计这类附加功能，开启后按量计费。

这里有个容易踩的坑：很多人只比较存储单价，忽略了计算节点和备份空间的权重。100TB的数据，计算节点哪怕只用中低规格，一个月也要几千到上万元；备份空间如果免费额度不够，轻松再多出几万元。后续我会在测算部分把这些全部算进去。

还有计费模式的问题。PolarDB和大多数云数据库一样，支持包年包月和按量付费。按量付费灵活，适合短期测试；长期稳定业务选包年包月，单价通常更便宜。另外存储空间也有类似“存储包”的预付费形式，买对了能再省一截，我后面会详细讲。

2. PolarDB凭什么把存储成本压下来

2.1 存储计算分离：从“自己盖仓库”到“租大仓”

要理解PolarDB为什么省钱，得先理解它的架构核心：存储与计算分离。

传统自建MySQL或者RDS那种“计算存储一体”的架构，相当于你自己盖了一栋仓库，仓库里必须配办公室、货架、装卸工。哪怕你只用了十分之一的空间，仓库的租金和维护成本一分不少。数据量小的时候无所谓，但到100TB规模，这种模式的成本几乎是线性膨胀的——你扩容计算，存储也连带着要加；你加存储，计算资源又闲置浪费。

PolarDB采用的是共享分布式存储，计算节点和存储节点解耦。打个比方：办公室还是你的办公室，但货物全部放到一个巨大的公共仓库里，用了多少平就付多少租金。计算资源不够就单独加办公室，存储不够就扩仓库，两边互不绑架。

这个架构直接影响成本结构。存储费用按实际使用量计费，业务没写入那么多数据，就不需要为预留空间买单。计算节点也可以独立伸缩，比如白天高峰用8核，凌晨低谷缩到2核，成本随业务曲线走。

2.2 一写多读与共享存储：只读节点不再“烧钱”

很多业务并不是单机就能扛住的，尤其是读多写少的场景，习惯性会加只读节点分担查询压力。传统MySQL主从复制架构下，每加一个只读节点，就要在存储上复制一份全量数据。100TB的数据，加两个只读节点，存储成本直接变成300TB的账。

PolarDB的做法完全不同。它的主节点和只读节点共享同一份存储，物理上数据只有一份。增加只读节点时，不需要复制数据，只需要为新增的计算节点付费。存储成本不会因为只读节点增加而翻倍。

这在100TB场景里差异非常明显。比如你当前需要一个主节点加两个只读节点来扛读写压力，传统架构存储开销大约是300TB，PolarDB只需要100TB。单这一项，存储成本就省了三分之二。

当然，这里有个前提需要说明：PolarDB底层的数据多副本、一致性协议等机制，在物理存储链路层面有自己的冗余设计，这部分成本被平台承担并通过一定方式体现在单价里。但从用户账单角度看，你只按一份逻辑存储付费，三副本之类的物理开销不需要自己单独掏钱。这其实就是云原生数据库“把复杂留给自己，把简单留给用户”的体现。

2.3 存储类型、压缩与冷热分层的省钱细节

除了架构层面的节省，PolarDB在存储细节上也有不少可以薅的“羊毛”。

首先是存储类型选择。PolarDB底层使用ESSD云盘，分PL0、PL1、PL2、PL3等性能等级。PL0便宜，适合数据仓库、日志等对延迟不敏感的场景；PL1是均衡配置；PL2和PL3性能更强但单价更高。100TB这个体量下，并不是所有表都需要最高性能的存储。业务上冷热分离做得好，选对存储等级，单价差距可以到一倍以上。

其次是数据压缩。PolarDB MySQL版对部分数据类型有压缩能力，尤其是字符型、日志型数据，压缩比通常可以达到2:1甚至更高。100TB原始数据，压缩后可能只需要40-50TB的存储空间，直接砍掉一半存储费。这个收益是实打实的，而且对业务透明，应用层不需要做任何改造。

再者是冷热分层和归档策略。PolarDB支持将历史分区放到成本更低的存储介质，或者通过DTS等工具同步到OSS归档。对于100TB规模的库，通常有相当一部分是低频访问的历史数据，把它们挪到低成本存储上，月度成本可能下降30%以上。

不过要提醒一句：压缩和冷热分层都需要结合业务访问模式来评估。如果是核心交易类数据，频繁更新且需要极致性能，压缩反而可能影响写入速度；低频历史数据做归档则要考虑查询时取回的成本。成本优化是系统工程，不是简单开个开关。

3. 100TB存储成本测算与方案对比

3.1 计费口径与100TB月度成本估算

下面进入最核心的环节：算账。我不打算堆官方文档里的超长价格表，因为云产品价格本来就会随时更新、分地域、分活动，我更想给你一个可复用的测算框架。

假设场景：主节点采用8核32GB规格，一个只读节点采用4核16GB规格，存储容量100TB，业务运行在中国内地某地域，按包年包月的存储包价格大致估算。请注意，以下数字是参考值，真实价格以控制台为准，但计算思路完全通用。

这里有几个容易被忽略的口径需要说清楚。第一，100TB存储如果走按量付费，单价大约是0.0014-0.002元/GB/小时，折算下来一个月可能到10万-14万元，和买存储包差距很大。所以长期稳定业务无脑买存储包，这是最基础的省钱操作。

第二，备份空间的免费额度，PolarDB不同版本和活动政策可能不一样，有的按存储空间一定比例赠送，有的送固定容量。100TB的库如果每天做全量备份，备份文件可能达到几十TB，一旦超出免费额度，新增费用非常夸张。建议在控制台开启“备份压缩”，并合理设置备份保留周期，比如只保留7天，而不是默认的30天。

第三，SQL洞察和审计功能不要盲目全开。100TB规模下，慢日志和全量SQL采集会产生大量写入和存储开销，如果只是临时排查问题，用完就关，别让它在账单里默默跑一年。

3.2 与RDS MySQL、自建方案的详细对比

没有对比就没有说服力。我把三种常见方案放在同一个表格里，按照100TB这个规模横向比较。

从这个表能看出来，PolarDB在100TB这个量级的优势主要体现在三个点：一是只读节点不重复消耗存储，二是不需要为了容量上限拆成几十个实例，三是存储包机制让大容量存储的边际成本更低。

自建方案看起来云盘单价差不多，但你还要额外算ECS实例费用、架构师的工时、故障处理的凌晨电话费。很多公司喜欢拿“自建便宜”说事，实际把人力成本和风险折算进去之后，云数据库在百TB规模往往更划算。

3.3 性价比结论：PolarDB的优势区间在哪

任何方案都有适用边界，PolarDB也不是所有场景都无脑最优。根据我的实际经验，它最合适的区间大概是这样：

• 数据量超过20TB，且未来还会增长。
• 读多写少，或者有明显的读写分离需求。
• 需要快速扩容，不想因为容量上限做分库分表。
• 团队DBA资源紧张，希望减少日常运维事务。

反过来，如果你的业务数据量只有几百GB，单机MySQL就能跑得很好，没必要上PolarDB；如果业务是一次性历史归档，写完就不再读，直接上OSS或者归档存储更便宜；如果对极致性能有变态要求，且能接受复杂运维，自建加定制优化也有它的价值。

所以说，100TB存储成本分析这件事，比的不是某一个单价的数字，而是整个系统架构和运维模型在当前规模下的综合效率。PolarDB的高性价比，是建立在大容量、多节点、弹性场景下的。

4. 从RDS MySQL迁移到PolarDB的实操与避坑

4.1 创建PolarDB MySQL版实例完整流程

讲完理论，上点实操。很多人好奇PolarDB和RDS MySQL从控制台到连接到底怎么操作，我这里以一个全新的PolarDB MySQL版集群为例，把步骤走一遍。

第一步：登录阿里云控制台，在顶部搜索框输入“PolarDB”，进入云原生数据库PolarDB管理页面。点击“创建集群”，选择地域，注意地域要和你的应用服务器ECS在同一个Region，否则走公网流量费用会很肉疼。

第二步：选择引擎。这里可以看到MySQL、PostgreSQL、兼容Oracle的语法模式等选项。如果你的业务是MySQL体系，直接选MySQL版，兼容性最好，从RDS迁移过来几乎不需要改代码。

第三步：配置计算规格。选择主节点规格，比如8核32GB，再根据需求配置只读节点。首次创建可以只建主节点，后续按需增加只读节点。网络类型选择VPC，提前创建好VPC和交换机。

第四步：设置数据库账号密码、集群名称、购买时长。这里有个小技巧：如果是测试环境，可以先按量付费创建，验证完再转包年包月；如果是生产环境，直接包年包月加购买存储包，价格最优。

第五步：创建完成后，在集群详情页可以看到“主地址”和“集群地址”。主地址是指向主节点的连接地址，集群地址会自动做读写分离和负载均衡，把读请求分发到只读节点。业务侧建议优先使用集群地址，让流量自动分流。

连接方式也很简单。如果你的ECS和PolarDB在同一个VPC内，在ECS上用mysql命令行直接连：

mysql -h your-cluster-address.mysql.polardb.rds.aliyuncs.com -u your_user -p -P 3306

首次连接前记得在控制台配置白名单，把应用服务器ECS的内网IP加进去。不配置白名单，即使密码正确也会报错。DBA如果习惯用DMS，也可以在控制台直接点“登录数据库”，网页上就能跑SQL，免去本地装客户端的麻烦。

4.2 从RDS MySQL迁移的路线和注意事项

从RDS MySQL迁移到PolarDB，最常见的方式是使用数据传输服务DTS。整个过程可以做到业务不停机迁移，步骤大概是：

1. 在DTS控制台新建迁移任务，源端选择RDS MySQL实例，目标端选择PolarDB集群。
2. 迁移类型选择“结构迁移+全量数据迁移+增量数据迁移”，这样旧库写入不停，新库持续同步。
3. 预检查通过后启动任务，等全量数据迁移完成，增量同步延迟降为0。
4. 在业务低峰期将应用连接串切换到PolarDB集群地址。
5. 观察一段时间，确认无异常后停止DTS任务，释放RDS实例。

这个流程我跑过多次，有几点必须提醒。第一，迁移前一定要先在测试环境做一次完整演练，尤其是数据结构里有特殊类型、外部触发器、定时任务的情况，DTS的映射规则不一定百分之百兼容。第二，大表建议提前做索引优化，PolarDB的存储引擎优化器逻辑和RDS略有差异，迁移后跑一遍慢查询日志，把缺失的联合索引建上。第三，业务侧连接池的参数要适配，PolarDB的集群地址后端节点数会变化，连接池最大连接数不要设死。

额外提一句连接指南里的常见坑：很多人在本地用Navicat或MySQL Workbench连PolarDB，发现连接超时。90%的原因是白名单没有加自己的公网IP。排查时先别怀疑配置，看一眼控制台白名单列表，通常都是这里的问题。还有PolarDB的账号权限体系和RDS不完全一样，比如某些管理账号没有SUPER权限，这是为了安全，不是bug。

4.3 成本优化落地清单与常见坑实录

最后给大家一份可以直接抄作业的成本优化清单，结合我自己的踩坑经验：

1. 购买存储包：100TB场景，存储包比按量付费一个月能省几万元，这是优先级最高的操作。
2. 选择合适的计算规格：不要为了“性能冗余”买过高规格，PolarDB可以随时升配，先从小规格跑起来观察负载，不够再升。
3. 只读节点按需创建：每次大促或压测前加节点，结束后及时删除。只读节点虽然不复制存储，但计算费用是实打实的。
4. 精简备份策略：缩短备份保留周期，开启备份压缩，把备份成本压到免费额度内。
5. 关闭不用的增值功能：SQL洞察、审计日志这类功能，用的时候再开，用完就关。
6. 冷数据归档：超过半年不访问的历史表，通过DTS同步到OSS，或转为PolarDB的归档存储，释放高成本存储空间。

我遇到过的一个典型问题：客户在PolarDB控制台看到“存储空间自动扩容”默认开启，就没管它。结果某个业务bug触发大量临时数据写入，存储从60TB飙到110TB，一个月的存储账单翻了快一倍。后来我们帮他把临时表放到独立的临时实例里，给核心集群设置存储告警阈值，才算控制住。这里也提醒大家，自动扩容是保命功能，但一定要配好告警，别让它变成失控的源头。

另外还有一个坑是关于地域的。存储包和集群必须在同一个地域才能抵扣，有些人看某个地域存储包便宜就买了一个，结果集群在另一个地域，根本抵扣不了。买之前先在集群详情页确认地域，再下单。

最后再分享一个我个人的小技巧

处理100TB这种规模的数据，我习惯在每个月底固定做一次“账单体检”：打开费用中心，把存储、计算、备份、流量四项列出来，环比看一遍，任何一项涨幅超过20%，都要找到具体原因。很多成本失控都是小问题积累出来的，比如某个只读节点忘了释放，某个备份保留周期被误改了，一个月多出几千块，不刻意查根本发现不了。

这套方法配合PolarDB的弹性能力，是目前我处理大容量数据库成本问题比较顺手的一套打法。如果你的数据量也在往100TB这个方向走，希望这篇能帮你把账算明白，少踩几个坑。