是否建议定期变更RDS实例规格以实现夜间缩容？

完全理解你的需求——针对这种仅工作日白天高负载、夜间/周日几乎闲置的业务，通过定期调整RDS实例规格来降本，确实是非常合理的思路，而且你已经手动验证过可行性，这点很棒！

先说结论：这种方案是完全可行且值得推荐的，下面从合理性和潜在注意点两方面给你梳理：

为什么推荐？ #

• 降本效果直接：夜间CPU只有2%，从m5.4xlarge降到m5.large，能大幅削减RDS的小时计费成本，长期下来节省的开支很可观。
• 完美适配你的场景：不用彻底停服，既能保留夜间定时任务的运行能力，也能满足少数非工作时间用户的访问需求，比直接关机的方案更灵活。
• 风险可控：你已经手动测试过，变更带来的2分钟左右停机时间在低峰期完全可接受，不会影响核心业务体验。

需要留意的潜在细节/风险 #

虽然整体风险很低，但有几个点还是要提前考虑：

• 连接中断的影响：变更过程中数据库连接会暂时中断，要确保你的应用有自动重连机制，避免夜间少量用户遇到连接失败的问题；另外如果有夜间定时任务，最好把变更时间和任务执行窗口错开，防止任务被中断。
• 特殊功能的限制：如果你的RDS实例绑定了只读副本、跨区域复制等特殊功能，要提前确认这些功能不会阻碍规格变更（不过同系列实例之间的变更一般不会有问题）。
• 自动化后的监控告警：如果用脚本或自动化工具来实现定时变更，一定要配套监控告警——比如某次扩容/缩容失败时，能及时收到通知，避免第二天高峰前没恢复到高规格导致性能崩盘。
• 缓存重建的微小影响：每次变更规格后，数据库缓存会重建，不过夜间访问量极低，这个过程几乎不会有感知，不用太担心。

其实这种“按需调整资源”的思路本身就是云服务的核心优势之一，之所以网上相关内容不多，可能是因为很多人要么选择直接停服，要么用更复杂的架构，但你的场景下，直接变更实例规格是最简洁高效的方案。

备注：内容来源于stack exchange，提问作者Alexander Ledig