摘要

  • RDS 自动扩容只负责增加空间。同一数据库实例已经获得的存储配额不能原地调小，因此数据用量下降不会自动压低这部分容量账单。
  • 符合条件的 MySQL 实例可以借助蓝绿部署换到更小的环境，但复制、切换、双环境运行及旧恢复历史的保留，会影响节省的时间与金额。

打扫卫生，房东不会重画户型

数据库清理完成后，最容易出现一种令人愉快的错觉：占用量降了，成本问题也解决了。监控面板一片宽裕，团队终于可以把这项任务划掉。账单却仍按原来的大房间收费。

看 RDS for MySQL 的官方价格说明，存储费用对应的是已经配置给实例的容量，月内容量发生变化时按期间折算。里面放了多少数据，是另一个数字。即使删除和整理确实释放了文件系统空间，只要分配容量没有减少，存储费的计算基数就仍在那里。

这正是自动扩容留下的后续工作。AWS 的存储自动扩容文档写明，自动化可以增加空间，却不会缩小已经分配给数据库实例的容量；在同一个实例上手动修改，也不能把它调低。关闭自动扩容同样不会撤销先前的扩张。

这项功能有很实在的价值。数据库快满时，及时补上空间，可以避免团队在故障边缘仓促操作。问题出在两个时刻被混为一谈：扩容当时需要更多容量，事后是否仍值得保留全部容量。前一件事可以自动完成，后一件事需要有人作决定。

系统把危险的满盘变成了安全的空余。企业如果没有后续复查，就会把一次临时的救急购买，当成长久的默认配置。自动化成功地保住了业务，也成功地把下一步工作留给了人。

要住小房子，得搬一次家

RDS 留有降低容量的路径。对于支持的数据库引擎，客户可以建立存储更小的绿色环境，通过蓝绿部署接替原有生产环境。另一条路径是新建更小的实例，迁移数据并切换访问端点。两条路都涉及替代环境，原实例不会因为数据少了就自己收缩。

蓝绿部署创建说明还给出了缩容底线：目标容量至少比当时的实际使用量大 20%。用一个纯粹的算例看，已分配 500 GiB、使用率为 50%，对应使用量 250 GiB，按文档公式得到的最低目标为 300 GiB。配置是否支持、创建期间还会增长多少，都要继续检查。这是容量算术，不能直接当作客户的省钱成绩单。

容量降低会启动存储配置升级。这类操作耗费输入输出资源，并可能延长新环境的准备时间。对企业来说，财务提出“把那个大数字改小一点”，技术团队拿到的却是一项需要复制数据、核对行为和安排切换的任务。两边看到的工作量很不一样。

本文的具体对象是符合蓝绿部署条件的 RDS for MySQL 实例。支持列表还覆盖指定版本的 MariaDB 和 PostgreSQL，Db2、SQL Server、Oracle 则不在这条路径的支持范围内。不同引擎的退路要分别核实，不能给所有 RDS 数据库发一张相同的“缩容券”。

搬走生产流量，还没搬走所有成本

AWS 的切换流程会检查复制健康状况、延迟等条件，暂停新的写入，断开连接，等待新环境追平数据，再调整实例与端点名称，放行新生产环境的连接和写入。手动单独提升绿色实例是另一个操作，会破坏蓝绿部署所依赖的复制关系。省钱的愿望没有取消切换步骤。

接入地址可以沿用，底下的资源身份却已经换了。更容易被成本表漏掉的是历史恢复能力。按照 AWS 的限制与注意事项，旧生产实例的时间点恢复历史不会转移给新生产实例。新实例保留自己的资源标识，其可恢复历史从绿色环境创建时开始。旧蓝色实例则在删除前保有自己的历史和自动备份。

企业如果仍需恢复到更早的业务时点，就要考虑继续保留旧环境。AWS 明确提醒，保留运行的蓝色实例仍会产生计算和存储费用。于是，较小的生产环境已经上线，短期总开支却可能高于迁移之前。新容量的节省和旧容量的退场，发生在两个日期。

还有一个容易让清理工作假性完成的按钮：删除蓝绿部署不会影响蓝色环境。删除的是部署关系，旧数据库资源仍然存在。把 MySQL 实例停下来，也仍有存储费用。真正结束某项收费，要查相应资源是否还保留，而非只看部署列表是否清爽。

实际净收益缺的是客户的容量价格、并行运行时间、恢复保留需求和迁移工时。把这些补齐，才能知道什么时候回本。规则本身已经足够明确：清理数据降低使用量，完成替代和旧资源交接，才可能降低为此购买的容量。漂亮的空闲率图表不是最后一张验收单。