云数据库 RDS 怎么选：实例规格与备份的实践笔记

最近给一个小项目选数据库，我把自建 MySQL 和云数据库 RDS 比了一遍，最后还是选了 RDS。这篇笔记把选型时真正纠结过的几个点记下来，供同样刚入门的朋友参考。

一、先想清楚：什么场景适合用 RDS

RDS 适合数据本身就是业务核心、但团队不想在运维上花太多精力的场景。比如常见的 Web 应用、内部管理系统和小程序后端，用户数据和订单数据丢不起，又没有专职 DBA。它把安装、打补丁、主备切换和备份这些事接了过去，应用只管连上去用。如果只是本地做实验，自建反而更自由。

二、实例规格：先够用，再留余量

选规格，我先看三个数：CPU、内存和并发连接数。入门练手或日活不高的内部系统，2 核 4GB 的通用型通常够用；如果联表查询和报表统计比较多，内存要优先加，因为 MySQL 很吃缓冲池，内存一小，查询一多就容易变慢。存储要看数据量和增长速度：初期几十 GB 够用，但要选支持弹性扩容的存储，数据涨上来可以在线扩。我的做法是先按当前数据量的两倍估算，再留出半年的增长空间。

三、存储类型：别只看价格

RDS 的存储大致分两类：注重低延迟的本地盘，和可以弹性扩容、可靠性更高的云盘。选的时候问自己两个问题：数据丢了能不能接受重建？业务高峰时读写延迟能不能忍？两个答案都指向稳妥，那就优先云盘加高可用。另外要留意 IOPS 上限，批量导入和大表迁移时很容易把 IOPS 打满，错峰操作。

四、备份与恢复：平时不做，出事就晚了

自动备份我一般这样设：每天凌晨业务低峰做一次全量备份，保留 7 天以上；同时开启 Binlog，保留时间和全备保持一致。这样恢复时可以选择任意时间点，不只是回到昨天凌晨。我还定期做一次恢复演练：把备份恢复到一个临时实例，确认数据能读、表结构完整，再删掉临时实例。重要操作前，比如大批量更新和删表，手动先做一次备份。

五、连接数与安全组：先通，再收紧

应用连不上 RDS，多数时候不是数据库坏了，而是连接数或安全组没放行。先查实例的最大连接数，再看应用的连接池配置：连接池开得比实例上限还大，高峰时一定会报错。我的做法是把连接池上限设在实例上限的七成左右，留出余量给管理连接和突发流量。安全组只放行应用服务器所在的 VPC 和内网地址，公网访问默认不开；临时从本地连，先放行自己的出口 IP，用完就收回。应用账号只给业务库的读写权限，不用 root 账号跑业务。

小结

选 RDS 不用一步到位，但备份、连接数和安全组这三件事要在上线前就定下来。规格可以以后升，数据丢了却补不回来。