分布式数据库的计费比单机数据库复杂，因为它的架构天然拆成了多个角色，每个角色都能独立扩缩。理解这些角色怎么收费，是做数据库上云成本预估的前提。这篇文章把分布式数据库（以阿里云 PolarDB-X 为例）的计费构成和三种付费模式拆开讲，帮你在稳定负载和波动业务之间找到更划算的组合。
存算分离架构决定了费用构成
PolarDB-X 采用存算分离架构，计算和存储是独立的资源池，分别计费。一次查询从发起到返回，会经过三类节点：
- 计算节点（CN）：负责 SQL 解析、路由、分布式事务协调，是承接应用并发的主力。计算规格越高、节点数越多，能承载的并发越大，费用也越高。
- 数据节点（DN）：负责数据的持久化存储与多副本一致性。按实际占用的存储容量计费，数据量增长存储成本随之上升，但与计算资源相互独立。
- 元数据服务（GMS）：管理全局元信息和全局事务时钟（TSO），由平台随集群规模统一调度，用户一般不需要单独为其规划预算。
存算分离的关键好处是：扩存储不必连带加计算，加算力也不必多买存储。你只为真正用到的资源付费，而不是像一体机那样把两种资源捆绑在一起买。这一点对成本结构影响很大——数据量猛增但并发平稳的场景，可以只扩 DN 而不动 CN，费用增长是可预期的。
除了这三类核心资源，还有两项按需计费的附加成本：跨可用区网络流量和数据备份。不用就不产生费用，按需开启即可。
三种计费形态分别适合谁
PolarDB-X 提供包年包月、按量付费和 Serverless 三种计费形态，对应不同的业务负载曲线。
包年包月（预付费）
预付费锁定单价，适合长期稳定的核心业务。单价相对最低，预算可控。缺点是资源一旦包年包月就固定了，遇到临时流量高峰需要额外叠加弹性资源。
选它的情况：线上核心交易库、订单系统、长期跑批的业务库，负载基本平稳，不会有剧烈峰谷。
按量付费（后付费）
按小时计费，随开随停，没有长期绑定。单价高于包年包月，但灵活。适合短期测试、压测、临时扩容或业务验证阶段。
选它的情况：新业务上线初期不确定规格、临时做性能压测、灰度环境需要随时释放。
Serverless（按实际用量弹性计费）
按秒级实际用量结算，自动弹性伸缩：流量上来自动扩，流量下去自动缩。低峰期几乎不产生计算费用。适合有明显峰谷波动、低峰期较长的业务。
选它的情况：电商大促、营销活动类业务、白天忙晚上闲的内部系统、流量不可预测的初创项目。
怎么组合才能既稳又省
实际项目中，更常见的做法不是二选一，而是组合使用：
- 把基础负载用包年包月锁定低单价，覆盖日常 80% 的流量。
- 把峰值部分交给按量付费或 Serverless 承接，只在高峰期才花钱。
- 结合云监控和智能诊断工具，观察资源利用率，定期调整包年包月的规格和弹性资源的触发阈值。
这样做的核心思路是：稳定部分锁价，波动部分弹性兜底。比起自建分库分表集群——需要按峰值预留硬件、平时利用率低、还要投入中间件维护和 DBA 人力——存算分离的按需计费在综合 TCO 上通常更有优势，尤其当团队规模小、运维人力有限时。
选型时容易忽略的几点
- 存储成本会随数据量线性增长，如果业务数据膨胀快（比如日志、历史订单），要提前预估 DN 费用，而不是只盯着计算规格。
- 跨可用区部署会产生额外流量费用，高可用架构通常跨 AZ，这部分成本要计入预算。
- 备份策略影响成本，高频备份和长期归档会增加存储费用，按合规要求设定合理的保留周期即可。
- Serverless 的弹性有冷启动延迟，对延迟敏感的在线交易场景，建议保留一定的基础规格而不是完全依赖缩到零。
分布式数据库的计费并不神秘，关键是搞清楚自己业务的负载曲线，再匹配对应的计费形态。稳定负载锁价、波动负载弹性，是控制云数据库成本的基本原则。